Monografia Vesao Leitura em PC PDF

Universidade de Braslia
Instituto de Cincias Exatas

Departamento de Cincia da Computao
OpenFlow e o Paradigma de Redes Definidas por

Software
Lucas Rodrigues Costa
Monografia apresentada como requisito parcial

para concluso do Curso de Computao Licenciatura
Orientador
Prof. Dr. Andr Costa Drummond
Braslia
2013
Universidade de Braslia UnB

Curso de Computao Licenciatura
Coordenador: Prof. Dr. Flvio de Barros Vidal
Banca examinadora composta por:

Prof. Dr. Andr Costa Drummond (Orientador) CIC/UnB
Prof. Dr. Jacir Luiz Bordim CIC/UnB
Prof. Dr. Wilson Henrique Veneziano CIC/UnB
CIP Catalogao Internacional na Publicao

Costa, Lucas Rodrigues.
OpenFlow e o Paradigma de Redes Definidas por Software / Lucas
Rodrigues Costa. Braslia : UnB, 2013.
305 p. : il. ; 29,5 cm.
Monografia (Graduao) Universidade de Braslia, Braslia, 2013.
1. Redes Definidas por Software (RDS), 2. OpenFlow, 3. POX,
4. MiniNet
CDU 004.4
Endereo:
Campus Universitrio Darcy Ribeiro Asa Norte
CEP 70910-900
BrasliaDF Brasil
OpenFlow e o Paradigma de Redes Definidas por

Software
Lucas Rodrigues Costa
Monografia apresentada como requisito parcial

para concluso do Curso de Computao Licenciatura
Prof. Dr. Andr Costa Drummond (Orientador)

CIC/UnB
Prof. Dr. Jacir Luiz Bordim

CIC/UnB
Prof. Dr. Wilson Henrique Veneziano

CIC/UnB
Prof. Dr. Flvio de Barros Vidal

Coordenador do Curso de Computao Licenciatura
Braslia, 8 de maro de 2013
Dedicatria
Dedico a todos os professores que passaram na minha vida dos quais pude tirar os
conhecimentos necessrios que contriburam para este e outros trabalhos em minha
vida. Dedico a minha famlia e meus amigos que me ajudaram com apoio moral
nessa longa jornada.
Agradecimentos
Agradeo primeiramente a Deus por ter me ajudado nessa caminhada, a minha
famlia pelo apoio e ajuda, a minha noiva Adriana, pela pacincia e compreenso
nos momentos difceis e principalmente a meus professores da universidade, em
especial ao professor Andr Costa Drummond que me apresentou rea de redes de
computadores, a qual me identifiquei muito.
ii
Resumo
As redes de computadores se tornaram parte da infraestrutura crtica de nossa
sociedade, participando do cotidiano de bilhes de pessoas. O sucesso das redes de
computadores se deve, em grande medida, a simplicidade de seu ncleo. Na arquitetura atual, a inteligncia da rede est localizada nos sistemas de borda, enquanto
o ncleo simples e transparente. Embora essa abordagem tenha tido sucesso, viabilizando a Internet, tambm a razo para sua inflexibilidade e incapacidade de se
atender as necessidades das novas aplicaes que devero surgir no futuro prximo.
A inflexibilidade da arquitetura das redes de computadores tambm traz um desafio para os pesquisadores da rea, pois seus experimentos dificilmente podem ser
avaliados em redes reais. Sendo assim, em geral, testes de novas tecnologia so realizadas em simuladores de rede, o que implica em uma simplificao da realidade.
O paradigma de Redes Definidas por Software (Software Defined Networks - SDN)
e a arquitetura OpenFlow oferecem um caminho para a implementao de uma arquitetura de rede programvel, capaz de ser implementada de forma gradativa em
redes de produo, que oferece a possibilidade de separao dos mecanismos de
controle dos diversos fluxos de trfego atendidos, de forma que, por exemplo, um
experimento cientfico possa ser executado em uma rede real (adaptada para o SDN)
sem interferir em seu funcionamento.
O presente trabalho contextualiza os problemas existente nas redes de computadores atuais, e apresenta o paradigma de redes SDN como uma das principais
propostas para a viabilizao da Internet do Futuro. Nesse contexto, o trabalho discute a arquitetura OpenFlow que permite a criao de aplicaes para redes SDN. O
trabalho tambm apresenta o simulador de redes SDN MiniNet, que implementa a
interface OpenFlow. Finalmente so implementados exemplos de uso da arquitetura
OpenFlow no MiniNet com o intuito de preparar um conjunto de cenrios que sirva
como base para a realizao de pesquisas na rea de redes SDN, ou como ferramenta
didtica para o ensino de conceitos complexos em redes de computadores.
Palavras-chave: Redes Definidas por Software (RDS), OpenFlow, POX, MiniNet
iii
Abstract
The computer networks have become an important element of the critical infrastructure of our society. The success of these networks is mainly due to the simplicity
of its core. In the current architecture the network intelligence is located at the edge
devices while the core remains simple and transparent. Although this approach has
been successful, making the Internet a reality, it is also responsible for the inflexibility and the inability to cope with the needs of the novel network applications that will
arise in the near future.
The inflexibility of today networks brings a challenge for the researchers in the
field, because it makes the evaluation of scientific experiments almost impossible to
carry on in real networks. Thus, frequently, new technologies are test in simulation
environments, which might be an over simplification of the reality. The Software
Defined Networks (SDN) approach and the OpenFlow architecture provide means for
the implementation of a programmatic network, which allows its gradual deployment
in production networks, and oer ways to separate dierent control mechanisms for
dierent network flows which enables, among other things, a scientific experiment
to be done in a real network (SDN capable one) without interfering with its operation.
This paper the main issues of todays networks and presents the SDN approach
as one of the main proposals to enable the Future Internet. It discusses the OpenFlow
architecture as a way to implement SDN applications. The MiniNet simulator is also
presented as a tool to evaluate SDN scenarios by implementing the OpenFlow Interface. Finaly, some examples are implemented with the MiniNet in order to compile
a set of network scenarios, which might serve as basis for new research in the SDN
field, or as a powerful didactic tool for teaching complex network concepts.
Keywords: Software Defined Network (SDN), OpenFlow, POX, MiniNet
iv
Sumrio
1 Introduo
1.1 Motivao . . . . . . . .
1.2 Objetivos . . . . . . . .
1.3 Metodologia . . . . . . .
1.4 Organizao do Projeto
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Reviso Terica
2.1 Histria das Redes de Computadores
2.2 Arquiteturas Atuais . . . . . . . . . . .
2.3 Evoluo das Redes de Computadores
2.4 Arquiteturas do Futuro . . . . . . . . .
2.5 Redes Virtualizadas . . . . . . . . . .
2.6 Redes Definidas por Software . . . . .
2.7 Sistema OpenFlow . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Redes Definidas por Software

3.1 Sugimento das Redes Definidas por Software
3.2 Motivaao . . . . . . . . . . . . . . . . . . . .
3.3 Arquitetura . . . . . . . . . . . . . . . . . . .
3.4 Elementos Programveis das redes SDN . . .
3.5 Divisores de Recursos . . . . . . . . . . . . .
3.6 Controlador SDN . . . . . . . . . . . . . . . .
3.6.1 NOX . . . . . . . . . . . . . . . . . . .
3.6.2 POX . . . . . . . . . . . . . . . . . . .
3.6.3 Maestro . . . . . . . . . . . . . . . . .
3.6.4 Beacon . . . . . . . . . . . . . . . . .
3.6.5 Floodlight . . . . . . . . . . . . . . . .
3.6.6 Frenetic . . . . . . . . . . . . . . . . .
3.6.7 Onix . . . . . . . . . . . . . . . . . . .
3.6.8 SNAC . . . . . . . . . . . . . . . . . .
3.6.9 Trema . . . . . . . . . . . . . . . . . .
3.7 Aplicaes . . . . . . . . . . . . . . . . . . . .
3.7.1 Controle de Acesso . . . . . . . . . . .
3.7.2 Gerenciamento de Redes . . . . . . .
3.7.3 Gerenciamento de Energia . . . . . .
3.7.4 Comutador Virtual Distribudo . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
.
.
.
.
.
.
.
4
4
7
11
14
16
18
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
24
24
25
27
29
31
32
32
32
33
33
34
34
34
35
35
35
36
36
3.7.5 Redes Domsticas . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.7.6 Roteador Expansvel de Alta Capacidade . . . . . . . . . . . . . 38
3.7.7 Redes de Grande Porte . . . . . . . . . . . . . . . . . . . . . . . 38
4 OpenFlow
4.1 Pradro OpenFlow . . . . . . . . . . .
4.2 Componentes de uma Rede OpenFlow
4.3 Protocolo OpenFlow . . . . . . . . . .
4.4 Controlador OpenFlow . . . . . . . . .
4.5 Funcionamento . . . . . . . . . . . . .
4.6 Aplicaes do OpenFlow . . . . . . . .
4.7 O OpenFlow Atualmente . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Controlador POX
5.1 Capacidades do POX . . . . . . . . . . . . . . . . .
5.2 Instalao do POX . . . . . . . . . . . . . . . . . .
5.3 Executando o POX . . . . . . . . . . . . . . . . . .
5.4 Componentes do POX . . . . . . . . . . . . . . . .
5.5 Compreendendo a Funo launch() . . . . . . . . .
5.6 Ncleo do POX . . . . . . . . . . . . . . . . . . . .
5.7 Eventos no POX . . . . . . . . . . . . . . . . . . . .
5.8 Pacotes do POX . . . . . . . . . . . . . . . . . . . .
5.9 Threads no POX . . . . . . . . . . . . . . . . . . . .
5.10 OpenFlow no POX . . . . . . . . . . . . . . . . . . .
5.11 Mensagens OpenFlow no POX . . . . . . . . . . . .
5.11.1 of.ofp_packet_out . . . . . . . . . . . . . . .
5.11.2 of.ofp_flow_mod . . . . . . . . . . . . . . .
5.11.3 of.ofp_match . . . . . . . . . . . . . . . . .
5.11.4 ofp_action . . . . . . . . . . . . . . . . . . .
5.12 Desenvolvendo Componentes Prprios . . . . . . .
5.12.1 Como criar um componente bsico no POX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 MiniNet
6.1 Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 MiniNet na Prtica . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Pr-Requisitos . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Download VM MiniNet . . . . . . . . . . . . . . . . . . . . .
6.2.3 Configurao da VM MiniNet . . . . . . . . . . . . . . . . .
6.2.4 Notas sobre o Prompt de Comando . . . . . . . . . . . . . .
6.2.5 Acessando a VM MiniNet via SSH . . . . . . . . . . . . . . .
6.2.6 Instalando os Editores de Texto . . . . . . . . . . . . . . . .
6.2.7 Aprendendo as Ferramentas de Desenvolvimento . . . . .
6.2.8 Principais Comandos do MiniNet . . . . . . . . . . . . . . .
6.2.9 Comandos Utilizados para a Inicializao do CLI do MiniNet
6.3 Outros Comandos e Ferramentas da VM MiniNet . . . . . . . . . .
6.4 Teste o Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
41
42
43
44
45
47
48
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
50
51
51
52
53
54
54
55
56
58
60
60
60
60
61
61
61
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
65
65
65
65
66
67
68
68
69
73
77
82
7 Implementaes Desenvolvidas
7.1 Instalando e Configurando o POX . . . . . . . . .
7.2 Executando um Componente do POX no MiniNet
7.3 Cenrios de Simulao . . . . . . . . . . . . . . .
7.3.1 Componente HUB . . . . . . . . . . . . .
7.3.2 Componente SWITCH . . . . . . . . . . .
7.3.3 Componente SWITCHES . . . . . . . . . .
7.3.4 Componente FIREWALL . . . . . . . . . .
7.3.5 Componente ROUTER . . . . . . . . . . .
7.3.6 Componente ESPECFICO . . . . . . . . .
7.4 Resultados Esperados . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
84
85
86
87
89
89
90
91
92
93
8 Discusso e Concluso
94
8.1 Desafios de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Referncias
98
A Descrio dos Elementos do POX

B Cdigos das Implementaes
B.1 Cdigo do Terceiro Cenrio
B.2 Cdigo do HUB . . . . . . .
B.3 Cdigo do SWITCH . . . . .
B.4 Cdigo do SWITCHES . . . .
B.5 Cdigo do FIREWALL . . . .
B.6 Cdigo do ROUTER . . . . .
B.7 Cdigo do ESPECFICO . . .
102
Desenvolvidas
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
C API MiniNet (MiniGUI)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
112
. 112
. 113
. 115
. 117
. 118
. 121
. 126
132
vii
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
Diferenas entre as topologias do sistema telefnico e da ARPANET.

Pilha TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocolo TCP/IP [31]. . . . . . . . . . . . . . . . . . . . . . . . . . .
Representao dos tipos de arquitetura da Internet do Futuro [17].
Exemplo de uma rede virtualizada, com trs redes compartilhando
mesmo substrato fsico [33]. . . . . . . . . . . . . . . . . . . . . . .
2.6 Arquitetura do comutador OpenFlow [42]. . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
. . 5
. . 8
. . 9
. . 15
o
. . 17
. . 20
Arquiteturas de roteadores: modelo atual e modelo programvel [40].

Identificao dos fluxos OpenFlow pelo FlowVisor [20]. . . . . . . . . .
Fluxo de comandos do FlowVisor [14]. . . . . . . . . . . . . . . . . . . .
Principais controladores SDN. . . . . . . . . . . . . . . . . . . . . . . . .
25
28
29
31
4.1 Componentes de uma rede OpenFlow [33]. . . . . . . . . . . . . . . . . 43

4.2 Definio de um fluxo na arquitetura OpenFlow [19]. . . . . . . . . . . 44
4.3 Exemplo de uma tabela de fluxos de um comutador OpenFlow. O campo
representado por um * indica que qualquer valor aceito naquela
posio, ou seja um campo que no importa no reconhecimento do
fluxo [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Comparaes de desempenho entre o POX e o NOX [34]. . . . . . . . . 51
6.1 MiniNet API miniedit.py. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2 MiniNet API consoles.py. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.1 Primeiro Cenrio de Testes. . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2 Segundo Cenrio de Testes. . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.3 Terceiro Cenrio de Testes. . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.1 MiniGUI API minigui.py (API de inicializao do CLI do MiniNet). . . . . . 133
viii
Lista de Quadros
5.1 Opes de inicializao do POX. . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Atributos gerais dos Eventos OpenFlow no POX. . . . . . . . . . . . . . 58
6.1 Tipos de mensagens OpenFlow apresentadas ao iniciar o controlador. . 78
6.2 Tipos de mensagens OpenFlow apresentadas ao realizar um ping. . . . 79
A.1 Descrio dos Componentes nativos do POX. . . . . . . . . . .
A.2 Continuao do Quadro A.1. . . . . . . . . . . . . . . . . . . . .
A.4 Anlise da classe Ethernet do POX. . . . . . . . . . . . . . . . .
A.5 Anlise da classe IP do POX. . . . . . . . . . . . . . . . . . . . .
A.6 Anlise da classe TCP do POX. . . . . . . . . . . . . . . . . . . .
A.7 Argumentos de construo da classe Timer. . . . . . . . . . . .
A.9 Mtodos da classe Timer. . . . . . . . . . . . . . . . . . . . . .
A.10 Eventos fornecidos do mdulo OpenFlow no POX. . . . . . . .
A.11 Continuao do Quadro A.10. . . . . . . . . . . . . . . . . . . .
A.12 Definio dos atributos da classe of.ofp_packet_out do POX.
A.14 Definio dos atributos da classe of.ofp_flow_mod do POX. .
A.16 Definio dos atributos da classe of.ofp_match do POX. . . .
A.17 Definio de algumas das classes ofp_action do POX. . . . .
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
102
103
104
105
105
106
106
107
107
107
108
108
109
109
110
110
111
Captulo 1
Introduo
A infraestrutura mundial das redes de computadores constitui hoje um dos servios crticos da sociedade. Esta infraestrutura, chamada de Internet, prov uma srie
de servios que atendem a todos os setores da sociedade, sendo considerada um
sucesso. Todavia, as mesmas razes que permitiram o nascimento e o crescimento
da Internet, so vistas hoje como barreiras para seu desenvolvimento e, portanto,
ameaam sua capacidade de suprir as necessidades futuras da sociedade.
Essas barreiras levaram a comunidade cientfica a pensar em novas propostas
para atender essas necessidades. Tais propostas contribuem para a definio da Internet do Futuro. Embora tais propostas sejam capazes de atender as necessidades,
sua implementao difcil de ser realizada, pois, como as redes de computadores so parte da infraestrutura crtica da sociedade, mudanas tornam-se obstculos
quase intransponveis, e acabam sendo descartadas pelos administradores das redes.
Essa inflexibilidade na arquitetura da Internet tambm traz um desafio para os
pesquisadores da rea, pois seus experimentos acabam no sendo avaliados em
redes reais. Dessa forma, em geral, testes de novas tecnologias so realizados em
ambientes virtuais que simplificam a realidade no fornecendo, assim, o nvel de
fidelidade necessrio para uma implementao em redes reais.
O paradigma de Redes Definidas por Software (Software Defined Networks - SDN)
e o protocolo OpenFlow oferecem um caminho para vencer esse desafio, por meio
de uma soluo seja implantada de forma gradativa em redes de produo.
1.1
Motivao
O sucesso das redes de computadores evidenciou o trabalho de pesquisadores

da rea, mas sua chance de gerar impacto tornou-se cada vez mais remota. Isto
ocorre devido a dificuldade para a implantao de novos protocolos e tecnologias,
visto que novas propostas, em geral, requerem mudanas em todos os milhares de
equipamentos de rede instalados.
As redes de computadores so parte da infraestrutura crtica do nosso dia-a-dia, e
portanto mudanas tornam-se obstculos e acabam sendo descartadas pelos admi-
nistradores de rede. Todas essas barreiras dificultam a implantao de novas ideias

que acabam no sendo testadas em ambientes reais.
O paradigma de Redes Definidas por Software e o protocolo OpenFlow foram desenvolvido com esse propsito, viabilizar o teste de novas propostas em redes reais
sem afetar as redes de produo. Dessa forma, alm de atender os problemas da
inflexibilidade das redes de computadores, o paradigma SDN nos permite atender
as necessidades das novas aplicaes de rede que devero surgir em um futuro
prximo, resolvendo problemas associados a requisitos de escalabilidade, gerenciamento, mobilidade e segurana por meio de uma arquitetura de rede programvel.
1.2
Objetivos
Este trabalho tem como objetivos gerais:

Apresentar o paradigma de redes SDN identificando suas caractersticas e capacidades;
Apresentar o protocolo OpenFlow e suas caractersticas;
Apresentar os detalhes da arquitetura do controlador de redes SDN POX e os
elementos principais para a implementao de aplicaes no mesmo;
Por fim, apresentar o simulador de redes SDN MiniNet e todas suas caractersticas.
Este trabalho tem como objetivos especficos:
Mostrar as possibilidades da arquitetura de rede SDN;
Mostrar como utilizar um controlador de rede SDN, como o POX, para a implementao de diferentes solues na rea de redes;
Implementar componentes no POX que sirvam como ponto de partida para a
sua utilizao prtica.
1.3
Metodologia
O presente trabalho faz uma reviso bibliogrfica dos principais conceitos das redes de computadores, apresenta seu contexto histrico, sua evoluo, as tecnologias
atuais e do futuro, alm das implicaes deste contexto nos dias de hoje. apresentado o estado da arte, em redes de computadores, para resolver as imperfeies da
arquitetura atual. Dentre elas encaixa-se como a mais promissora as redes SDN e
o uso do protocolo OpenFlow em comutadores de produo. So apresentadas as
caractersticas deste paradigma de redes, as caractersticas do protocolo OpenFlow
e todos os elementos que compe o modelo de arquitetura deste paradigma.
So propostas implementaes de referncia que servem como base para o desenvolvimento de aplicaes na rea de Redes Definidas por Software. As implementaes propostas so validadas por meio de simulao e sua corretude atestada.
2
1.4
Organizao do Projeto
O restante do trabalho est organizado da seguinte forma. O Captulo 2 traz o

contexto histrico das redes de computadores, apresentando suas limitaes e as
inflexibilidades de sua arquitetura atual. O Captulo 3 aborda as Redes Definidas
por Software, apresentando suas caractersticas. O Captulo 4 apresenta uma ferramenta de virtualizao de redes, o protocolo OpenFlow. No Capitulo 5 apresentado
o controlador POX, um controlador de Redes Definidas por Software especialmente
desenvolvido para o ambiente de pesquisa e ensino. No Capitulo 6 apresentado o
simulador de redes SDN MiniNet, suas caractersticas, seu funcionamento alm de ser
posto em prtica com um exemplo simples e de fcil implementao. O Captulo 7
apresenta cenrios de teste que servem como ponto de partida para as primeiras
aplicaes de redes SDN. O Captulo 8 apresenta os resultados do trabalho, levantando desafios de pesquisa para o paradigma SDN e ressaltando a importncia da
arquitetura de Redes Definidas por Software nas redes de computadores do futuro.
Os Apndices esto organizados da seguinte forma. O Apndice A descreve alguns elementos do controlador POX. O Apndice B contm os cdigos das implementaes propostas neste trabalho. Por fim, o Apndice C contm o cdigo de uma API
desenvolvida neste trabalho para o simulador MiniNet.
Captulo 2
Reviso Terica
As redes de computadores se tornaram parte da infraestrutura crtica de nossas
empresas, casas e escolas, sendo um sucesso do cotidiano de bilhes de pessoas.
Desde sua origem, as redes de computadores tem crescido bastante e seu uso ficou
cada vez mais diversificado. A massificao das tecnologias de rede foi obtida, em
grande parte, pela sua boa adoo sistemtica no meio comercial, ao mesmo tempo
em que programas multiusurios comearam a ser desenvolvidos. Nesse contexto
as redes de computadores cresceram agregando milhes de equipamentos.
O sucesso das redes de computadores deve, em grande medida, a simplicidade de
seu ncleo. Na arquitetura atual, a inteligencia da rede est localizada nos sistemas
de borda, enquanto o ncleo simples e transparente. Embora essa simplicidade tenha tido sucesso, viabilizando a Internet, tambm a razo para seu engessamento.
Todas essas limitaes apresentam problemas estruturais que so difceis de serem
resolvidos, tais como escalabilidade, mobilidades e gerenciamento de servio [9].
Este captulo apresenta o contexto histrico das redes de computadores, sua evoluo durante os anos, as tecnologias atuais e do futuro, alm das implicaes deste
contexto nos dias de hoje. apresentado o estado da arte, em redes de computadores, para resolver as implicaes da arquitetura atual. Dentre elas encaixa-se como
a mais promissora o conceito de Redes Definidas por Software e o uso do protocolo
OpenFlow.
2.1
Histria das Redes de Computadores
As Redes de Computadores surgiram a partir de pesquisas militares no perodo

da Guerra Fria na dcada de 1960 quando dois blocos ideolgicos e politicamente
antagnicos exerciam enorme poder sobre o mundo. O lder de um desses blocos, os
Estados Unidos, temia um ataque do outro bloco, liderado pela Unio Sovitica, a uma
de suas bases militares. Um ataque poderia revelar todas as informaes sigilosas
dos Estados Unidos. Temendo tal ataque, o Departamento de Defesa dos Estados
Unidos desenvolveu uma rede de comunicao que tinha o objetivo de descentralizar
as informaes at ento concentrada em pontos especficos.
Como exemplo, pode-se citar as redes telefnicas, que eram organizadas seguindo uma topologia em estrela que continha pontos centrais (Figura 2.1a), dessa
maneira, se algum desses pontos sofresse um ataque sovitico a rede poderia se
desestruturar, causando um grande prejuzo e impacto na guerra.
Para descentralizar as informaes foi criado uma novo modelo de troca e compartilhamento das informaes entre as bases militares, constituindo a primeira rede
de computadores, a ARPANET (Advanced Research Projects Agency Network [39]).
A ARPANET foi projetada e constituda para ser uma rede tolerante a falhas e altamente distribuda. Sua estrutura era organizada seguindo uma topologia em malha
(Figura 2.1b) que utilizava comutao por pacotes entre seus ns.
(a) Exemplo de Topologia Estrela
(b) Exemplo de Topologia Malha
Figura 2.1: Diferenas entre as topologias do sistema telefnico e da ARPANET.

A ARPANET era formada por minicomputadores chamados IMP (Interface Message
Processors) conectados por linhas de transmisso de 56 kbps. Para garantir a confiabilidade, cada IMP era conectado a pelo menos dois outros IMPs criando assim
caminhos alternativos em caso de falhas. Caso acontecesse uma falha a mensagem
seria encaminhada automaticamente para rotas alternativas, problema que no era
possvel resolver utilizando uma topologia estrela 2.1a. Assim, cada n era constitudo por um IMP e um host conectados por um fio curto, no qual o host enviaria
uma mensagem de 8063 bits para seu IMP que, por sua vez, dividiria essa mensagem em pacotes de 1008 bits e os encaminhava de forma independente at o seu
destino [44].
Depois que a tenso entre URSS e EUA diminuiu, a ARPANET cresceu, pois os EUA
permitiram que pesquisadores desenvolvessem estudos para a ARPANET trazendo
mais usurios a rede. Com isso a dificuldade em administrar o sistema cresceu e
uma nova ARPANET surgiu com usurios que no tinham relaes militares.
O desenvolvimento na rede aconteceu de tal modo que todos os usurios se ajudavam e contribuam para a formao de uma rede de computadores global. Esse
crescimento trouxe dificuldades para a interconexo de novas redes demonstrando
que os protocolos da ARPANET no eram adequados e no serviam para o cenrio
atual. Nesse contexto pesquisadores comearam a procurar novas maneiras que
resolvessem este problema, esse esforo resultou na criao dos protocolos e do

modelo TCP/IP [7].
O TCP/IP foi criado com o objetivo de manipular a comunicao entre redes permitindo que o trfego de informaes fosse encaminhado de um lugar para outro com
confiabilidade, com pacotes de diferentes tamanhos, tratando e recuperando erros
de transmisso e falhas de sequenciamento de pacotes, alm de realizar controle de
fluxo, congestionamento e verificao de erros fim-a-fim.
Por meio da National Science Foundation (NSF) [36], o governo dos EUA e empresas particulares investiram na criao de backbones, que consistia em poderosos,
porm simples, computadores conectados entre si com a capacidade de dar vazo a
grandes fluxos de dados. Os backbones so ligaes centrais de um sistema de rede
mais amplo, ou mais elevado na hierarquia das redes de computadores.
O backbone pode ser comparado a uma grande estrada. Durante toda sua extenso h entradas e sadas para diversas cidades, as quais compem redes de menor
porte. Todas essas vias, ou pequenas redes, esto conectadas estrada principal.
possvel exemplificar backbones de ligaes intercontinentais, que por sua vez derivam de backbones nacionais at backbones regionais. Neste ultimo encontram-se
as empresas que exploram o acesso as redes de computadores e que nos fornece a
conectividade com tais redes.
A unio de todas as redes define uma interligao global chamada Internet.
importante destacar que a Internet no possui um nico dono. Isso acontece pelo fato
de que as conexes entre essas redes feita considerando as polticas locais de cada
instituio. Nesse sentido no h uma administrao centralizada, embora existam
organizaes que se dedicam a definir padres, normas e regras para sua utilizao
e disponibilizao, o que garante o seu funcionamento. Podemos exemplificar as
seguintes organizaes:
O World Wide Web Consortium (W3C) [46] que concentra-se na padronizao
de tecnologias da Web.
A OASIS (Organization for the Advancement of Structured Information Standards) [37] um consrcio internacional especializado no desenvolvimento de
padres para segurana da Web.
A Internet Engineering Task Force (IETF) [28] que concentra-se no desenvolvimento da arquitetura das redes de computadores e a operao uniforme da
mesma por meio de protocolos. Cada padro da IETF publicado como uma
RFC (Request for Comments) e est disponvel gratuitamente.
O IEEE (Institute of Electrical and Electronics Engineers) [27] uma organizao
que cria padres nas reas de tecnologia da informao, telecomunicaes,
medicina e sade, transporte e outros.
O comit ISO (International Organization for Standards) [29] o maior desenvolvedor de padres do mundo e mantm uma rede de institutos nacionais de
padronizao em mais de 140 pases.
2.2
Arquiteturas Atuais
Ao passar dos anos as redes de computadores foram crescendo tornando-se um

aglomerado de redes em escala mundial. A interconexo de milhares de computadores por meio de protocolos de comunicao padronizados que permite o acesso a
informaes e a todo tipo de servio de dados define a Internet, que proveniente
da expresso internetwork (comunicao entre redes).
Uma maneira simples de visualizar a Internet considerar uma nuvem com computadores conectados a ela. Essa nuvem considerada o ncleo das redes de computadores. uma nuvem dinmica e cresce a medida que crescem e nascem novas
redes.
A arquitetura atual das redes de computadores atende praticamente os mesmos
requisitos especificados na arquitetura da ARPANET, esses requisitos consistem em:
conectividade - permite que qualquer estao de qualquer rede possa enviar
dados para qualquer outra estao de qualquer outra rede;
generalidade - dar suporte a diferentes tipos de servios e aplicaes;
heterogeneidade - permitir a interconexo de diferentes dispositivos e tecnologias de rede;
robustez - efetuar a comunicao desde que exista algum caminho entre origem
e destino;
acessibilidade - facilitar a conexo de novas estaes ou redes.
Para atender tais requisitos a arquitetura atual das redes de computadores fundamentada em uma arquitetura monoltica baseada em um modelo em camadas conhecido como modelo TCP/IP. Baseado no modelo mais geral proposto pelo OSI/ISO1 ,
o modelo TCP/IP utilizado atualmente na Internet devido a sua abrangncia e abordagem geral de caractersticas descritas em cada camada [44].
O modelo TCP/IP, ou a pilha de protocolos TCP/IP, um padro industrial de protocolos destinados as redes de computadores sendo as principais peas da arquitetura
das redes de computadores atuais [31]. A arquitetura de redes tem como objetivo
realizar a interligao de computadores e redes, no importando o tipo, entre si. A
arquitetura TCP/IP est organizada em quatro camadas: a camada de aplicao; a
camada de transporte; a camada de rede; e a camada de enlace/fsico. (Figura 2.2).
Camada de Aplicao - A camada de aplicao localiza-se acima da camada de
transporte, tem a funo de prover servios para as aplicaes criando a comunicao, por meio de uma rede, com outras aplicaes. A camada de aplicao
responsvel por identificar e estabelecer a disponibilidade da aplicao nas
mquinas disponibilizando os recursos para que tal comunicao acontea. Ela
contm todos os protocolos de nvel mais alto tais como o SMTP(Simple Mail
1
Open Systems Interconnection - OSI o modelo lanado em 1984 pela International Organization
for Standardization - ISO para definir formalmente uma arquitetura padro para a comunicao entre
mquinas e redes heterogneas
Figura 2.2: Pilha TCP/IP.

Transfer Protocol), o FTP(File Transfer Protocol), o HTTP(Hypertext Transfer Protocol), DNS (Domain Name Service) e outros protocolos que foram includos no
decorrer dos anos com novas aplicaes e modificaes na rede.
Camada de Transporte - A camada de transporte situada entre as camadas de
aplicao e de rede, tem como funo promover um canal de comunicao
lgico fim-a-fim entre as camadas de aplicao rodando em diferentes computadores no se preocupando com os detalhes das camadas inferiores. Os
protocolos de transporte so implementados, em geral, nos sistemas de borda
da rede, j que por sua vez tem implementaes mais complexas e oferecem
um canal lgico fia-a-fim para a camada de aplicao.
Camada de Rede - A camada de rede responsvel pelo roteamento dos pacotes
entre fonte e destino. A camada de rede permite que os hosts envie pacotes em
qualquer rede garantindo que eles trafegaro independentemente at o destino, muitas vezes utilizando rotas diferentes chegando at mesmo em ordem
diferente daquela em que foram enviado. A camada de rede formada basicamente pelo protocolo IP que tem como caracterstica o melhor esforo (best
eort), isto , faz o melhor esforo para envio de um pacote entres os hosts no
dando nenhuma garantia de entrega, obrigando ento as camadas superiores
tratarem suas limitaes.
Camada de Enlace/Fsica - A camada de enlace/fsica responsvel pela transmisso e recepo de quadros da camada de rede de um dispositivo para a
camada de rede de outro dispositivo fisicamente adjacente, estabelecendo um
controle de fluxo por meio de um protocolo de comunicao entre sistemas.
O modelo TCP/IP tem o objetivo de reduzir a complexidade da arquitetura de rede
por meio da diviso e do isolamento das funcionalidades da rede, permitindo que
cada camada preste servio para a camada superior. Nesse contexto o modelo TCP/IP
faz com que a cada passagem entre as camadas haja um encapsulamento da camada
superior em um novo tipo de pacote em que so adicionados cabealhos dos devidos protocolos das camadas correntes, o desencapsulamento ocorre no receptor, e
tambm nos roteadores ao longo de sua rota, conforme mostra a Figura 2.3.
8
Figura 2.3: Protocolo TCP/IP [31].

Alm disso a arquitetura atual das redes de computadores baseia-se na utilizao
da comutao em pacotes, que divide uma informao ou mensagem em diversas
unidades de tamanhos variveis chamados de pacotes, em geral menor que o tamanho da mensagem original, e os envia por caminhos alternativos da origem at o
destino [44].
Essa caracterstica somada a uma topologia em malha garante a robustez e a
conectividade da rede, pois com caminhos alternativos h uma garantia que se um
n da rede falhe o fluxo de dados no ser interrompido, pois os pacotes podem
procurar um novo caminho na rede caso haja uma infraestrutura existente, ou seja,
um outro caminho da estao origem ao destino.
A utilizao da comutao em pacotes tambm garante a eficincia da rede pois
os ns evitam o desperdcio de recursos devido ao compartilhamento da banda disponvel [31]. Assim, os pacotes compartilham os recursos da rede usando totalmente
a banda disponvel do enlace no desperdiando seus recursos como acontece no
caso do paradigma de comutao por circuitos, onde os recursos so dedicados ao
fluxo de dados no havendo o compartilhamento dos recursos do enlace.
Cada pacote enviado utilizando o servio de melhor esforo. O servio de melhor
esforo no requer que os ns sejam complexos garantindo a heterogeneidade da
rede, permitindo assim a interconectividade de diferentes dispositivos e tecnologias.
Essa caracterstica resulta em computadores simples e de baixo custo no ncleo das
redes. Por esse motivo, o ncleo das redes de computadores no garantem nenhum
controle de fluxo nem tempo de envio, nem mesmo a entrega dos pacotes, deixando
toda a responsabilidade de controle para as extremidades, ou seja, os computadores
na borda da rede.
A rede tambm baseia-se na ideia de ser transparente, ou seja, o pacote encaminhado da origem at o destino sem que a rede modifique seus dados, garantindo
a generalidade da rede e, portanto fornecendo suporte a diferentes tipos de servios
e aplicaes [35].
Outra ideia a do transporte fia-a-fim que consiste em esconder do usurio final
a complexidade do transporte dos dados. Dessa forma o ncleo da rede tem apenas
a funo de encaminhar os pacotes, com a qualidade do servio de melhor esforo.
O transporte fim-a-fim prov a comunicao lgica entre os processos de aplicao

executados nas estaes de origem e destino.
Outra soluo para o atendimento dos requisitos das redes de computadores
o uso do endereamento global que garante a acessibilidade da rede, facilitando
a conexo de novas estaes e novas redes na Internet. O endereamento global
garante a unicidade de cada n, com base nessas informaes que as decises de
encaminhamento dos pacotes so tomadas. Esse endereamento conhecido como
endereo IP (Internet Protocol) que alm de identificar os ns, prov uma forma de
localizao dos ns na rede global.
Em seguida novos requisitos foram includos na Internet tais como o controle distribudo, o clculo global do roteamento e a diviso em regies [35]. Todos estes
requisitos e solues so os princpios que configuram os protocolos e a estrutura
das redes de computadores atuais.
Controle Distribudo - permite a diviso do sistema de controle em mdulos interconectados por meio da rede de comunicao, proporcionando a diviso do
processamento, a reduo de custo, alm de facilitar o diagnstico e manuteno do sistema e de aumentar a sua flexibilidade e agilidade [43].
Calculo global de roteamento - define os caminhos que os pacotes devem seguir
de uma estao de origem a uma estao de destino. Se a rede utiliza o paradigma de comutao por pacotes a deciso de roteamento tomada para cada
pacote. Se a rede utiliza o paradigma de comutao por circuito, o caminho a
ser seguido definido no estabelecimento do circuito virtual de maneira que
todos os pacotes da mensagem devem seguir este caminho.
Diviso em regies - a Internet formada por um conjunto de redes de computadores interconectadas entre si [31]. Cada rede pode ser independente uma da
outra e por sua vez pode utilizar regras e polticas de encaminhamento diferentes. Cada rede ou conjunto de redes, que operam sob um mesmo conjunto
de regras administrativas define um Sistema Autnomo - SA (Autonomous System- AS). Cada SA se conecta a Internet por meio de um provedor de servio
de Internet (Internet Service Provider - ISP) que opera o backbone conectando
o cliente a outros provedores de servio. A comunicao entre cada SA realizada pelo protocolo BGP (Border Gateway Protocol) que troca informaes
entre SAs vizinhos.
A colaborao entre os diferentes SAs garante que a rede seja totalmente distribuda. Esse tipo de estrutura atribu robustez a Internet, pois caso algum SA falhe ou
restrinja a comunicao, a rede constri rotas alternativas que no utilizaro tal SA.
Na Internet, as redes de acesso so interconectadas segundo uma hierarquia de
nveis de ISPs. No topo dessa hierarquia existe um nmero relativamente pequeno
de ISPs denominados Tier 1 ou ISPs de nvel 1. Esses ISPs so especiais com capacidades de transmitirem pacotes a taxas extremamente altas, tem uma cobertura
internacional e conectam-se diretamente a cada um dos outros ISPs de nvel 1 [31].
Esse ISPs tambm so conhecidos como redes de backbone da Internet e por sua
vez prestam servies para os ISPs de nvel 2 (Tier 2).
10
Um ISP de nvel 2 normalmente tem alcance regional ou nacional e conectam-se

apenas a alguns poucos ISPs de nvel 1. O ISP de nvel 2 denominado um cliente
do ISP de nvel 1, que, por sua vez, denominado provedor do seu cliente. Abaixo
do Tier 2 esto os IPS de nveis mais baixos que se conectam a Internet por meio de
um ou mais IPSs de nvel 2 e, na parte mais baixa dessa hierarquia, esto os IPSs
de acesso.
2.3
Evoluo das Redes de Computadores
A utilizao do modelo em camadas, a transparncia e o principio fim-a-fim permitiram o crescimento da Internet. No entanto o fato da sua popularidade e do seu
tamanho terem crescido absurdamente durante os ltimos anos levou a incapacidade
de sua estrutura suportar o grande nmero de usurios. Hoje as mesmas causas que
levaram ao crescimento da Internet so as causas do seu engessamento e restrio
do seu crescimento. Nesse sentido a estrutura das redes de computadores vem se
modificando aos poucos para atender seus requisitos inicialmente propostos.
A Internet foi criada dando destaque generalidade e heterogeneidade na camada de rede [35], ou seja, a Internet feita de diversos e distintos dispositivos que
podem se interconectar de maneiras diferentes. Sua estrutura, ou seja, seu backbone consiste de simples, porm poderosos, computadores que formam o ncleo da
rede. Nesse sentido o ncleo da Internet simples e transparente com inteligncia
nos sistemas de borda, que por sua vez so ricos em funcionalidades. Alm disso
sua administrao descentralizada, pois consiste na interligao de diversos SAs.
Todo esse contexto leva ao famoso engessamento das redes de computadores.
Um ncleo simples, que se baseia no melhor esforo, no capaz de fornecer
informaes sobre o funcionamento interno da rede. Isso implica que o usurio fique
frustrado quando algo no funciona, pois ele no obtm informao sobre tal erro.
Outra consequncia a grande sobrecarga de configuraes manuais, depuraes
de erros e complexidade no projeto de novas aplicaes.
Para resolver esses problemas a estrutura das redes de computadores vem se
modificando, ao longo do tempo, por meio de adaptaes [35]. Todas essas adaptaes foram introduzidas durante o tempo para atender as novas necessidades e
requisitos, alm do aumento da demanda que no estavam previstas no projeto original. Assim as redes de computadores vem sendo modificadas de diversas maneiras
para fornecer uma maior escalabilidade, mobilidade, gerenciamento e segurana [9].
O servio de nome de domnios (DNS) uma dessas modificaes. O DNS um
sistema de gerenciamento de nomes hierrquico e distribudo operando para resolver
nomes de domnios em endereos de rede IP [31]. Outra dessas modificaes foi a
introduo do CIDR (Classless Inter-Domain Routing) que permite as organizaes
obterem uma faixa identificadora de rede de tamanho variavl [31]. Alm dessas
modificaes podemos destacar a criao de sub-redes, de sistemas autnomos e
modificaes no protocolo TCP (Transmission Control Protocol).
O protocolo IP tambm sofreu modificaes, entre elas podemos destacar o IP
multicasting, que permite que um host envie pacotes de dados para um grupo de
11
hosts; o IPv6, que aumenta o nmero de endereos disponveis, simplifica o cabealho antigo, permitir a identificao de fluxos entre outras coisas; O NAT (Networking
Address Translation), que faz com que um conjunto de hosts passe a ser endereado
por um nico endereo de IP; e muitas outras modificaes.
Todas essas modificaes foram necessrias para atender as demandas que vinham crescendo para as redes de computadores. As adaptaes na arquitetura
atual da Internet demonstram que seu projeto inicial no atende mais aos requisitos
atuais, e tambm no podemos ajust-los para as necessidades futuras. Nesse sentido a arquitetura atual das redes de computadores apresenta inmeros problemas
ainda no solucionados tais como: o problema de endereamento IP, a mobilidade
da rede, a segurana, o gerenciamento, a escalabilidade, alm da disponibilidade de
servio e sua qualidade.
Endereamento - O endereamento contm problemas associados a escassez de
endereos e ao nmero de informaes que um endereo IP carrega, tais como
localizao e identificao [30]. Temos tambm problemas da falta de autenticidade do endereo, visto que uma estao pode-se passar por outra usurpando
seu endereo IP. Mesmo com as modificaes propostas para o endereamento
IP tais como NAT, DNS e CIDR a Internet tem crescido tanto que essas modificaes j no conseguem suprir todas as necessidades atual tais como problemas
de segurana, autenticidade, replicao de dados e servios de rede.
Mobilidade - Cada vez mais cresce o nmero de dispositivos mveis que utilizam
a Internet sem fio. A questo da mobilidade consiste na transio entre os ns
mveis em diferentes pontos de acesso sem que haja a perda da conexo. Essa
questo fere alguns princpios do projeto original da Internet e mesmo com as
modificaes propostas para resolver este problema, hoje a arquitetura atual
das rede de computadores j no atendem mais satisfatoriamente os requisitos
atuais.
Segurana - Problemas como a disseminao de vrus, a negao de servio e
spams no foram previstas no projeto inicial da Internet. Hoje esses problemas esto cada vez maiores atingindo cada vez mais usurios na rede. Dessa
maneira fez-se necessrio que a segurana fosse tratada pela borda da rede,
ou seja, os computadores finais. Mesmo com essas modificaes ataques distribudos de negao de servio, por exemplo, ainda consistem em um problema
na arquitetura atual.
Gerenciamento - Na arquitetura atual das redes de computadores o gerenciamento
da rede feito de forma distribuda com inteligncia nas bordas. O crescimento da Internet tem prejudicado esse gerenciamento devido a dificuldade
de se gerenciar distribuidamente tantos fluxos de dados. Alm disso a arquitetura atual no dispe de ferramentas de diagnstico que possam identificar a
origem de problemas de funcionamento tornando o gerenciamento ainda pior.
Uma das modificaes para se resolver esse problema foi o protocolo SNMP
(Simple Network Management Protocol) [10]2 . No entanto o SNMP restringe2
Simple Network Management Protocol - SNMP um protocolo de gerenciamento de rede que

realiza o intercmbio de informao entre os dispositivos de rede.
12
se basicamente a monitorao dos dispositivos da rede fornecendo apenas um

diagnstico simples dos dispositivos de rede, deixando ainda em aberto o problema de gerenciamento de aplicaes e servidores. Dessa maneira o SNMP
insuficiente para atender as necessidades atuais.
Escalabilidade - A escalabilidade um dos maiores problemas da Internet atual. O
aumento do nmero de estaes nas redes leva a um aumento exponencial nas
tabelas de roteamentos dos dispositivos do ncleo da rede. Alm disso, com o
aumento do nmero de estaes, aplicaes que demandam muita banda comearam a ser mais utilizadas, como o caso de aplicaes multimdia. Outro
problema da escalabilidade est relacionado as redes mveis, pois em grande
parte dos seus protocolos h restries quanto ao nmero mximo de ns por
rede.
Disponibilidade - A disponibilidade da rede consiste em oferecer um servio de
rede confivel, robusto e que fique sempre disponvel. No entanto, devido ao
tamanho crescimento nas redes de computadores, a infraestrutura atual da
Internet no capaz de oferecer tal servio. Embora a Internet tenha sido projetada para obter uma melhor disponibilidade de servio que uma rede telefnica, esta por sua vez oferece uma maior confiabilidade de entrega de dados.
Isso deve-se ao fato que a Internet utiliza a comutao por pacote e as redes
telefnicas utilizam a comutao por circuito. Embora a segunda tenha sua
confiabilidade de entrega dos dados garantida no contem a robustez que a
primeira tem. Todavia, os servios atuais de disponibilidade j no so mais suficientes no contexto atual devido a inmeras falhas dos provedores de servio
e dos usurios. Estudos mostram que apenas 35% das rotas ficam disponveis
por 99,9% do tempo [32], o tempo de indisponibilidade de servios na rede devido a erros de software e de usurios chega a 40% do tempo de conexo [8].
Disponibilidade do acesso a rede sem fio chega a 43% abaixo do divulgado [3]
devido a infraestrutura da rede. Isso demonstra a necessidade de uma nova
arquitetura que seja capaz de lidar de maneira mais eficiente com erros e que
simplifique as tarefas dos usurios, uma vez que o perfil das pessoas que acessam a rede se modificou.
Qualidade de Servio - A Qualidade de Servio (Quality of Service - QoS) tem sido
amplamente estudada pela comunidade cientifica, no entanto prover QoS na arquitetura atual da Internet uma tarefa complicada devido s vrias restries
que a infraestrutura da rede atual impe. Implementaes para dar suporte
ao QoS vo contra a estrutura atual da rede, pois qualquer mecanismo de reserva de banda ou mudana de prioridade nos pacotes iro afetar o principio
de melhor esforo. interessante que os provedores de servios ofeream QoS
para se destacar na concorrncia de mercado, no entanto bastante complicado garantir o QoS devido ao fluxo de dados da origem ao destino, que muitas
das vezes atravessarem diversos SAs durante a comunicao. Assim, para se
garantir o QoS na arquitetura atual necessrio que haja um acordo entre os
diversos SAs de origem ao destino do pacote. Dessa forma torna-se necessrio
projetar uma nova arquitetura de rede para lidar com este problema.
13
Como foi apresentado, as modificaes realizadas na arquitetura da rede atual

j no so suficientes para atender alguns problemas recentes, alm disso algumas
modificaes ferem os requisitos da Internet. Sendo assim, se faz necessrio a introduo de mudanas no ncleo da rede, porm essas mudanas no so bem vistas
entre os administradores de rede, devido ao fato destes no arriscarem a implementao de novos servios que possam indisponibilizar, mesmo que por pouco tempo,
o uso da rede, ou que no sejam efetivamente melhores.
A falta de confiabilidade nestes novos servios deve-se ao fato que pesquisadores
ao criarem novos protocolos no conseguem, em geral, testar estes em redes reais,
somente em redes simuladas por meio de simuladores de rede. Dessa maneira esses
novos servios no garantem que so melhores que os servios atuais e por muitas
vezes no so postos em prtica, pois os administradores no querem correr o risco
de indisponibilizar seu servio.
Enfim, acaba se tornando um problema sem soluo, pois novos protocolos no
so testados em redes reais, devido a necessidade de mudanas em milhares de
equipamentos legados, e por esse motivo provedores de servio no adquirem confiana necessria para a ampla implementao em ambientes reais. Dessa forma,
muitos pesquisadores consideram que a infraestrutura de rede est ossificada, no
podendo ser modificada [19].
2.4
Arquiteturas do Futuro
As sees anteriores mostraram que a simplicidade da arquitetura atual das redes

de computadores juntamente com os requisitos preestabelecidos da pilha de protocolos TCP/IP permitiu o seu crescimento fcil e rpido j que as novas aplicaes
que surgiam no necessitavam realizar modificaes no ncleo da rede, apenas nos
computadores de borda. No entanto esses mesmos motivos que fizeram a Internet
crescer foram os mesmos motivos que pararam seu crescimento.
A Internet se tornou ossificada tornando suas modificaes de difcil implementao [19]. O grande crescimento da Internet trouxe diversos problemas estruturais que j no podem ser resolvidos apenas com modificaes da arquitetura atual.
Dessa maneira sua estrutura simples que levou a Internet a crescer, agora est limitando seu crescimento. Algumas das necessidades atuais s podem ser solucionadas com mudanas estruturais [2], portanto necessrio uma nova arquitetura para
atender os requisitos atuais e os requisitos das futuras aplicaes que sero ainda
propostas.
As arquiteturas do futuro para as redes de computadores so propostas que visam promover a flexibilidade com a capacidade de mudar e evoluir gradativamente,
dando suporte inovao no ncleo da rede. Os modelos que demonstram a Redes
de Computadores do Futuro podem ser divididos em duas abordagens ou paradigmas, a abordagem purista e a abordagem pluralista [11, 17, 2].
A abordagem purista, modela as redes de computadores em uma arquitetura monoltica, com uma nica pilha de protocolos executando sobre a estrutura fsica das
redes (Figura 2.4a).
14
Essa abordagem assemelha-se a arquitetura atual das redes de computadores

com a diferena que os protocolos nela utilizados devero ser flexveis e adaptveis
o suficiente para garantir a interoperabilidade dos elementos de rede aos novos requisitos e demandas. Nesta abordagem a virtualizao e as redes sobrepostas so
apenas ferramentas que podem ser usadas para agregar novas funcionalidades no
fazendo parte de um aspecto fundamental da arquitetura em si.
A segunda abordagem, pluralista, aborda uma arquitetura voltada a mltiplas
pilhas de protocolos executando simultaneamente (Figura 2.4b). Essa abordagem
faz com que diversas redes possam executar em paralelo para atender aos requisitos
de cada nova aplicao. Alm disso, sua implementao pode acontecer de forma
gradual, pois esta abordagem compatvel com a atual.
(a) Arquitetura Atual e Purista
(b) Arquitetura Pluralista
Figura 2.4: Representao dos tipos de arquitetura da Internet do Futuro [17].

Todas as abordagens pluralistas baseiam-se na ideia de executar mltiplas redes
virtuais sobre um substrato fsico compartilhado [17]. Nessa abordagem as tcnicas
de virtualizao de redes tornam-se fundamentais para permitir a coexistncia em
paralelo de mltiplas arquiteturas de protocolos. Com a virtualizao de redes as redes virtuais, no entanto, iro se diferenciar no formato dos pacotes, na maneira como
ser tratado o endereamento dos pacotes e nas execues dos protocolos, portanto,
cada pilha de protocolos, embora divida o mesmo substrato fsico, independente.
Comparando as duas abordagens apresentadas, a abordagem purista apresentase ainda mais complexa do que a pluralista. A abordagem purista torna-se mais
complexa pois a nova arquitetura e novos protocolos de rede tero de ser capazes
de resolver todos os problemas atuais e o problemas que ainda esto por vir.
J a abordagem pluralista mais simples no sentido de que sua implementao
se dar de forma gradual de maneira que cada rede virtualizada possa atender a
necessidade de cada nova aplicao, visto que toda sua ideia baseia-se em executar
redes virtualizadas sobre um substrato fsico compartilhado.
Existem outras abordagens alm das abordagens purista e pluralista na literatura.
Sendo essas arquiteturas que resolvem problemas especficos, como roteamento, segurana, qualidade de servio entre outros. Alm dessas abordagens no resolverem
o problema, como um todo, no est claro como integrar essas diversas arquitetu15
ras em um nico arcabouo consistente, visto que essas arquiteturas em geral so

incompatveis umas com as outras, no podendo ser usadas simultaneamente.
A abordagem purista defende a ideia que essas solues especificas poderiam
ser integradas a uma nica arquitetura devido a sua flexibilidade. Por outro lado, os
pluralistas defendem a ideia que tais redes especificas poderiam atuar simultaneamente por meio de tcnicas de virtualizao de redes. Ambas as ideias so muito
discutidas no meio acadmico [2].
2.5
Redes Virtualizadas
Como j apresentado, a injeo de novas ideias e implementaes no ncleo da

rede sofre discriminao pelos administradores de rede devido a falta de confiana
no bom funcionamento na rede, devido aos riscos de indisponibilizar a rede, alm do
custo benefcio a eles envolvidos. Uma das propostas vistas como alternativas para
o desenvolvimento de inovaes juntamente ao trfego de produo dar-se com a
virtualizao de redes.
Para explicar a virtualizao de redes, vamos primeiro explicar a virtualizao de
sistemas. A virtualizao de sistemas uma tcnica que permite que um n computacional, ou seja, uma mquina, execute mltiplos processos oferecendo a cada
um deles a iluso de estar executando sobre recursos dedicados. Dessa forma cada
mquina virtual acessa interfaces similares a mquina real. Para que as mquinas virtuais tenham a impresso de estarem sendo executadas sobre uma maquina real, os
ambientes virtuais devem ser isolados, ou seja, a execuo de uma mquina virtual
no deve interferir na outra, assim uma mquina virtual deve ter acesso a mquina
real como se fosse a nica.
Nesse contexto a virtualizao de redes tambm faz uma abstrao de um recurso. A virtualizao de redes passou a permitir que os componentes de uma rede fsica compartilhassem sua capacidade de maneira que realize simultaneamente mltiplas funes, estabelecendo infraestruturas lgicas distintas e mutuamente isoladas provendo um mtodo para que mltiplas arquiteturas de rede distintas compartilhem o mesmo substrato fsico. Em outras palavras uma rede virtual uma rede
composta pela interconexo de um conjunto de roteadores virtuais que representam
uma fatia de roteadores fsicos compartilhados.
Como as redes virtuais so isoladas, o trfego experimental no afetar o trafego
de produo (Figura 2.5). Esse modelo consiste em uma das principais abordagens
para as redes de computadores do futuro, em que cada rede virtual isolada e possui
sua prpria pilha de protocolos e seu gerenciamento individual.
A topologia de uma rede virtual no precisa ser idntica topologia de uma rede
fsica, embora seja necessrio uma rede fsica para transportar os dados. Uma rede
virtual uma rede composta por roteadores lgicos conectados em uma determinada
topologia. Dessa maneira os enlaces virtuais so criados pelo particionamento do
enlaces fsicos, tal particionamento corresponde a uma fatia da banda disponvel
no enlace fsico, portanto, a banda do enlace fsico dividida entre os enlaces virtuais.
16
Figura 2.5: Exemplo de uma rede virtualizada, com trs redes compartilhando o
mesmo substrato fsico [33].
Como a representao da topologia das redes virtuais no necessariamente
igual a topologia da rede real, para representar roteadores virtuais adjacentes em
roteadores fsicos no adjacentes, utiliza-se o tunelamento, que cria tneis entre
os roteadores fsicos para tornar a rota de transmisso transparente para a topologia
virtual. Essa caracterstica de poder mapear a rede virtual em uma rede fsica permite
que as redes virtuais sejam bastante flexveis. Para que haja essa flexibilidade se faz
necessrio uma funo de migrao de redes.
Uma funo de controle fundamental nas redes virtualizadas a migrao de redes virtuais. A migrao faz a movimentao dos ns das redes virtuais sobre os
ns da rede fsica [47]. Podemos aplicar a migrao de diversas maneiras como por
exemplo a manuteno de ns na rede, que muitas das vezes causa uma quebra
na conexo devido ao seu desligamento causando um atraso para que as rotas sejam reorganizadas entre os ns. Assim com a migrao poderamos contornar este
cenrio com uma simples migrao do n virtual para um n fsico que esteja em
funcionamento. Dessa maneira as redes virtuais garantem que a topologia lgica
no seja alterada e assim as rotas continuem vlidas.
Alm dos casos de manuteno podemos destacar os casos de ataques de negao de servio, bastando trocar todos os ns do substrato em ataque para outros
ns fsicos fora da regio do ataque, casos para economia de energia, quando h ns
fsicos subutilizados a migrao pode os detectar na rede fsica e assim poderem ser
desligados entre outros.
A migrao de redes virtuais ainda sofre alguns desafios tais para remapear os
enlaces virtuais sobre um ou mais enlaces fsicos e como reduzir o tempo de migrao, visto que os ns virtuais ficam indisponveis durante o processo possibilitando
a perda de pacotes no ncleo da rede. As redes virtuais trazem novos horizontes
para o ncleo da rede, com essa grande flexibilidade as redes virtuais permitem a
instanciao, a remoo e a configurao de recursos de redes virtuais sob demanda
permitindo tambm que as redes sejam monitoradas enquanto esto ativas. Dessa
maneira a virtualizao tem sido amplamente usada para o desenvolvimento de propostas para a Internet do Futuro [35], e para o desenvolvimento de redes experimentais. Dessa forma, a comunidade cientifica comeou a investir mais no tema, pois as
17
redes virtuais so capazes de oferecer ambientes reais para testes de novas ideias.
Nesse contexto, os pesquisadores de rede esto trabalhando em algumas redes
virtuais programveis como a GENI [26], um centro de investigao para a experimentao de novas arquiteturas de rede e sistemas multiusurios. Esse tipo de rede
tem como objetivo possibilitar a experimentao de protocolos em larga escala por
meio de Switches e Roteadores programveis utilizando virtualizao. Assim, essa
rede deve possuir Switches e Roteadores espalhados por todo o mundo que podem
ser modificados para executar protocolos experimentais. A proposta da GENI em
geral oferecer ao pesquisador uma fatia dos recursos da rede que consiste em
enlaces, roteadores, switches e terminais para que ele possa executar seus experimentos, por meio da virtualizao, podendo configurar seus recursos como desejar.
As redes virtualizadas, embora forneam uma grande flexibilidade para controlar
o ncleo da rede, carregam consigo algumas desvantagens. O gerenciamento de
uma rede virtual se parece muito com o gerenciamento de uma rede fsica, alm
disso temos uma banda muito limitada, visto que a banda de enlace virtual uma
fatia da banda fsica real. Outro problema o mapeamento dos ns virtuais entre
os reais, que exige grande ateno, pois se um dos ns fsicos parar de funcionar
todos os ns virtuais a ele referenciados deixaram de funcionar at que haja uma
migrao, causando prejuzos e atrasos na transmisso da rede.
Nesse contexto, o paradigma de redes virtuais parte de uma das abordagens e
propostas para a Internet do Futuro. A abordagem pluralista se baseia nessas redes
como parte de sua arquitetura, garantindo maior flexibilidade no ncleo da rede,
permitindo que diferentes requisitos de aplicaes sejam atendidos. Esse paradigma
possibilita que inmeros elementos de redes virtuais possam co-existir em um nico
equipamento fsico, mas possui ainda enormes desafios a serem vencidos para que
esta arquitetura seja uma realidade.
2.6
Redes Definidas por Software
Mesmo com o grande crescimento e evoluo da Internet, observamos que sua

arquitetura no evoluiu suficientemente nos ltimos anos. Embora todas as modificaes realizadas, a arquitetura de Internet j no est mais atendendo as demandas
das novas aplicaes.
Lembramos tambm que com toda essa evoluo das redes de computadores, a
mesma tornou-se comercial e nesse sentindo os equipamentos de rede tornaram-se
caixas pretas, ou seja implementaes integradas baseadas em software e hardware proprietrio. O resultado de toda essa evoluo causou o j comentado engessamento da redes de computadores [19]. Em contraste a essa realidade os pesquisadores de redes e a comunidade cientfica comearam a desenvolver novas propostas
para a criao da redes de computadores do futuro, ou seja, novas arquiteturas de
implementao do ncleo da rede.
Uma das principais propostas para essa nova arquitetura das redes de computadores baseia-se em redes capazes de ser programadas sob demanda, ou seja, redes
que sejam programveis ou redes que sejam flexveis para lidar com requisitos e
18
problemas atuais e futuros. Uma das formas de se prover programabilidade s redes

por meio da implementao de Redes Definidas por Software.
Redes Definidas por Software, ou redes programticas, so redes cujo substrato
fsico composto por equipamentos de propsito geral e a funo de cada equipamento, ou conjunto de equipamentos, realizada por um software especializado [33].
As Redes Definidas por Software so baseadas na separao entre o plano de controle
e o plano de dados.
O plano de controle responsvel pelos protocolos e pelas tomadas de deciso
que resultam na confeco das tabelas de encaminhamento. O plano de dados, tambm chamado plano de encaminhamento, cuida da comutao e repasse dos pacotes
de rede. Como j mencionado, nos equipamentos atuais ambos, o plano de controle
e de dados, so executados e implementados no prprio equipamento, impedindo
qualquer tomada de deciso que no tenha sido prevista nestes protocolos.
Para que haja uma tomada de deciso, necessrio quebrar essa restrio permitindo que o equipamento de rede encaminhe os pacotes por meio de protocolos e
implementaes externas sendo abrigadas em uma mquina fsica ou virtual. Nesse
sentido o plano de controle ser independente daquele pr-configurado e no se
limitar aos protocolos implementados pelo proprietrio ou fabricante.
Para que se estabelea uma interface de comunicao entre o plano de controle
e o plano de encaminhamento necessrio que os desenvolvedores criem APIs para
que se possa realizar tal comunicao. No entanto, isso acarretaria na criao de
mltiplas APIs diferentes para cada fabricante. Para resolver esse problema podese optar pela padronizao destas APIs. Mesmo com a padronizao, ainda assim
haveria uma limitao nas possveis aes a serem desempenhadas pelo plano de
controle, j que estas mais uma vez deveriam ser previstas pelo software do equipamento.
O OpenFlow [42] uma proposta que permite a implementao das Redes Definidas por Software, uma vez que estabelece uma interface de comunicao entre o plano de encaminhamento e o plano de controle com um padro de interface
bastante flexvel para que seja possvel a instalao de regras de encaminhamento
baseadas em diversos parmetros de protocolos de camadas distintas.
Sendo assim, existem duas principais correntes para prover o conceito de Redes
Definidas por Software em redes na arquitetura do Futuro. A primeira representada
pelo OpenFlow, uma tecnologia promissora, que prov alto desempenho e controle
da rede, a outra corrente representada pelas propostas de arquiteturas de redes
baseadas em redes virtualizadas, a qual fornece uma grande flexibilidade para controlar o ncleo da rede. Ambas fazem parte da abordagem pluralista de arquiteturas
da Internet do Futuro.
2.7
Sistema OpenFlow
As redes virtualizadas como a GENI so interessantes para diminuir as barreiras

para o surgimento de novas ideias e testes dessas mesmas, porem a implementao
dessas redes podem ser custosas devido sua grande escala [19]. Para permitir a ex19
perimentao de novas propostas para redes de computadores em escalas menores,

foi proposto o Comutador OpenFlow [42], cujo maior objetivo possibilitar que um
pesquisador execute seus experimentos em uma rede real. Nesse sentido a plataforma OpenFlow tem como objetivo criar um ambiente de rede de teste programvel,
unindo as qualidades da virtualizao de redes com o conceito de Redes Definidas
por Software.
A virtualizao de redes, utilizando uma rede IP sobre IP, consegue de maneira
simples criar uma rede de testes com uma escala considervel [35]. Os elementos
desse tipo de rede virtual so roteadores que executam sobre uma plataforma de
virtualizao, ou seja, so roteadores virtualizados. Nesse cenrio, os roteadores
virtuais so mquinas virtuais que executam funes de roteamento.
Roteadores virtuais agem de maneira similar aos roteadores fsicos convencionais, mas o desempenho dos roteadores virtuais inferior ao dos roteadores fsicos
convencionais, pois esse tipo de virtualizao tem a inconvenincia de utilizar implementaes baseadas na arquitetura das redes atuais apresentando problemas de
isolamento nas operaes de entrada e sada do roteador fsico. Desse maneira qualquer nova proposta realizada em redes virtualizadas, IP sobre IP, tem a desvantagem
de carregar consigo as caractersticas e limitaes da arquitetura atual da rede.
O OpenFlow uma plataforma de virtualizao de redes baseada na comutao de fluxos. A diferena que o comutador OpenFlow utiliza o conceito de redes
definidas por software, cujo o substrato fsico composto pela parte que cuida do
trfego de produo da rede e outra parte que cuida do trfego experimental das
novas propostas de rede. Assim, a plataforma OpenFlow procura oferecer uma opo controlvel e programvel, sem atrapalhar o fluxo de produo. Nesse sentido
o comutador OpenFlow encaminha os pacotes do trfego experimental de acordo
com regras definidas por um controlador centralizado. A arquitetura da plataforma
OpenFlow pode ser vista da Figura 2.6.
Figura 2.6: Arquitetura do comutador OpenFlow [42].
20
A vantagem do protocolo OpenFlow que com sua utilizao, pesquisadores podem testar suas experincias sem que interfira no trfego real da rede de produo
e sem a necessidade que os fabricantes de comutadores exponham os projetos de
software e hardware dos seus equipamentos.
O OpenFlow possibilita que os fabricantes dos roteadores atuais possam adicionar
as funcionalidades do OpenFlow aos seus comutadores sem necessitarem expor o
projeto de software e hardware do seus equipamentos. necessrio deixar claro
que esses equipamentos devem possuir baixo custo e desempenho semelhante aos
j utilizados, de forma que os administradores da rede aceitem a substituio dos
equipamentos j existentes.
O comutador OpenFlow tem como caracterstica a implementao em baixo custo,
pois no se faz necessrio que haja grandes mudanas no ncleo da rede. As mudanas podem ser realizada de forma gradual e no influenciaro o fluxo de produo da
rede. Assim, todas a polticas de roteamento e de trfego no sofrero mudanas e
caso sofram, essas no devero ser significativas. Dessa maneira sua implementao na infraestrutura ser realizada com um baixo custo e com um alto desempenho,
pois os pesquisadores no iro influenciar no trfego de produo, deixando o fluxo
de dados com desempenho semelhante ao de um comutador normal.
A arquitetura OpenFlow permite que vrios pesquisadores utilizem o comutador
para realizar vrias pesquisas ao mesmo tempo. Isso acontece, pois comutador
OpenFlow virtualiza o trfego experimental da rede para que as vrias pesquisas
possam compartilhar o mesmo fluxo experimental. Outro ponto importante no paradigma OpenFlow a generalizao do plano de dados, ou seja, qualquer modelo de
encaminhamento de dados que se baseie na tomada de deciso fundamentada em
algum valor do campo de cabealho dos pacotes pode ser suportada. Dessa maneira
a arquitetura OpenFlow pode suportar uma ampla gama de pesquisas cientficas.
A garantia do isolamento do trfego experimental do trfego de produo uma
das melhores caractersticas da arquitetura OpenFlow, pois permite que a infraestrutura se modifique sem que interfira na produo do SA. Isso acontece pois a arquitetura do comutador OpenFlow subdividida em dois planos, o plano de controle de
produo, implementado em hardware, e o plano de controle experimental, implementado no controlador OpenFlow e executado no hardware.
Os comutadores OpenFlow implementam mdulos que permitem a comunicao
com o controlador de forma independente e segura, separada do fluxo real da rede.
Dessa maneira as entradas na tabela do fluxo experimental dos comutadores so
interpretadas como decises em cache realizadas no hardware e so planejadas no
plano de controle no software. Em outras palavras isso quer dizer que as decises
do fluxo experimental so planejadas no software e executadas no hardware.
O OpenFlow apresenta vrias caractersticas que ajudam na difcil transio da
arquitetura atual para as arquiteturas do futuro. Visto que essa transio no pode
ser feita instantaneamente, o paradigma OpenFlow ir realizar essa transio de
maneira gradativa, pois as novas propostas dos pesquisadores podero agora ser
validadas em rede real no atrapalhando o fluxo de produo da rede. Dessa maneira os administradores de rede tero maior confiabilidade nas novas propostas de
roteamento, pois estas no foram validadas em redes simuladas, e assim aceitaram
implementar as novas ideias em suas redes.
21
Captulo 3
Redes Definidas por Software
Como podemos observar, apesar de toda essa evoluo formidvel das redes de
computadores, em termos de penetrao e aplicaes, sua arquitetura, que fez com
que sua evoluo fosse possvel, no evoluiu da mesma forma e por esse motivo j
no capaz de atender os requisitos atuais da Internet. Alm do mais, a Internet
se tornou comercial e por sua vez seus equipamentos de rede se tornaram caixas
pretas, isto , implementaes baseadas em software fechado sobre um hardware
prprio.
Dessa forma as redes de computadores se tornaram enormes e ao mesmo tempo
esto restringidas pelas suas prprias limitaes, sua arquitetura distribuda e fechada. Contrapondo a abordagem da arquitetura atual das redes de computadores,
surgiram ideias e pesquisas sobre a Internet do Futuro, pesquisas que visam resolver
os problemas at ento enfrentados pela sua arquitetura monoltica distribuidamente
fechada, tais como problemas associados ao endereamento, a mobilidade, a escalabilidade, o gerenciamento e a qualidade de servio.
As abordagens da Internet do Futuro visam resolver os problemas atuais e atender as novas demandas de requisitos estabelecidos pela Internet. Em geral essas
abordagens se caracterizam por por um plano de controle concentrado que permitem mover grande parte da lgica de tomada de decises dos dispositivos de redes
para controladores externos, que podem ser implementados com o uso de tecnologia
de servidores comerciais, um recurso abundante, escalvel e barato [40].
Nos equipamentos de rede tradicionais as tomadas de deciso ocorrem no seu
prprio interior, ou seja, o roteamento dos pacotes de rede definido por algortimos
previamente calculados geralmente fechados, de difcil ou impossvel modificao,
uma vez implementado em uma rede o equipamento toma suas prprias decises
para enviar o pacote.
Se o controle das tomadas de deciso fosse logicamente centralizado haveria
a possibilidade da definio do comportamento da rede em software, no apenas
pelos prprios fabricantes do equipamento, mas tambm por fornecedores ou pelos
prprios usurios, como, por exemplo, operadores de rede.
As Redes Definidas por Software (Software Defined Networks, (SDN)) constituem
esse novo paradigma para o desenvolvimento das redes de computadores. As redes
SDN abrem novas perspectivas em ambientes de controle lgico da rede, em novas
22
aplicaes de rede podendo ser desenvolvidas de forma simples e livre dos limites
da arquitetura atual.
3.1
Sugimento das Redes Definidas por Software
Como vimos no captulo anterior, as redes de computadores fazem parte da infraestrutura crtica do dia-a-dia da sociedade, logo novas propostas para novas solues
de rede fazem-se necessrias mas ao mesmo tempo so difceis de serem implementadas.
Isso ocorre devido ao risco de interrupo das atividades que pode ocorrer ao implementar essas novas propostas. H tambm problemas econmicos, pois a adoo
de novas ideias, em geral, requer de alteraes do hardware utilizado na rede, fazendo com que os administradores de rede inviabilizem tais reformas estruturais.
Esses problemas levam a ossificao das redes de computadores. A Internet atingiu um nvel de amadurecimento que a tornou pouco flexvel. Como visto anteriormente, a comunidade cientifica visa contornar esse problema com a implementao
de redes com maiores recursos de programao. Exemplos como a GENI [26] que
apostam em recursos de virtualizao de rede para permitir que se tornem programveis, apesar de ter um grande potencial, tiveram pouca aceitao pelos administradores de rede pela tamanha necessidade de alterao dos elementos de rede.
Uma maneira de contornar esse problema reduzindo o impacto de interferncia na
rede de produo, consiste em estender o hardware de encaminhamento de pacote
de forma mais restrita sobre um controle fino de trfego. Basta atribuir um rtulo
ao pacote que determinar como o mesmo sera tratado pelos outros elementos da
rede.
Dessa forma administradores de rede podem exercer controle diferenciado sobre
determinados trfegos na rede. Com base nessa caracterstica esse hardware permite que um administrador de rede desenvolva aplicaes de rede que determinam
como os fluxos sero tratados na rede de produo.
Foi com essa ideia que o desenvolvimento do protocolo de rede OpenFlow [42] partiu. O protocolo OpenFlow permite que os elementos de encaminhamento da rede,
os comutadores, possam conter uma interface de programao simples que permita
o acesso ao controle de fluxo, ou a tabela de comutao, utilizado pelo hardware. Assim o roteamento dos pacotes podero ser programveis de maneira que os pacotes
recebidos sejam encaminhados pelas portas programadas pelo administrador.
O encaminhamento dos pacotes ainda ser eficiente, visto que ocorrer ainda no
hardware, porm as decises de cada pacote encaminhado poder ser processado
por uma camada superior em que diferente funcionalidades podem ser implementadas. Essa estrutura permite que a rede seja controlada por meio de aplicaes
desenvolvidas em software. A essa nova abordagem da arquitetura de redes d-se
o nome de Redes Definidas por Software, ou Software Defined Networks (SDN).
23
3.2
Motivaao
A abordagem de redes SDN vem sendo muito pesquisada no meio acadmico. Isso
ocorre devido as diversas possibilidades de aplicao que esse paradigma traz para
as redes de computadores. As redes SDN se apresentam como uma forma potencial
de implantao da Internet do Futuro.
Propostas como o OpenFlow abordam a ideia de que no necessrio que a comutao de pacotes seja definida pelo principio de roteamento de redes IP. Os elementos da rede, roteadores e switches, no iro mais controlar a parte lgica do
processo de comutao de pacotes. O processamento de comutao de pacotes poder ser controlado por aplicaes em software desenvolvidos independentemente
do hardware.
No entanto o universo SDN muito maior que do que aquele definido pelo controle
do processo lgico de comutao, definido pelo padro OpenFlow. O OpenFlow
apenas uma das aplicaes abordadas pelas Redes Definidas por Software, o novo
paradigma abre tambm a possibilidade de se desenvolver outras aplicaes que
controlam os elementos de comutao de uma rede fsica de maneiras totalmente
distintas das que possveis com a arquitetura atual das redes de computadores.
O desenvolvimento dessas aplicaes torna-se possvel por meio de controladores
de rede, chamados de Sistemas Operacionais de Rede. Esses elementos oferecem
um ambiente de programao favorvel para o desenvolvimento dessas aplicaes,
como por exemplo, desenvolver tcnicas de roteamento para determinados tipos de
fluxos de dados na rede.
Os Sistemas Operacionais de Rede formam um ambiente de programao onde o
desenvolvedor pode ter acesso aos eventos gerados por uma interface de rede, por
exemplo o OpenFlow, gerando os comandos para controlar a estrutura de chaveamento e comutao. Com esse tipo de aplicao, torna-se mais simples implementar
polticas de segurana baseados em nveis de abstraes maiores que os atuais endereos IPs cobrindo todos os pontos de rede, por exemplo. [14]
As redes SDN possibilitam a implementao de aplicaes de rede que realizam
lgicas de monitorao e acompanhamento de trfego mais sofisticado e mais completo que os atuais.
3.3
Arquitetura
A arquitetura atual do roteadores de rede (Figura 3.1) formada basicamente por

duas camadas distintas: O software de controle; e o hardware dedicado ao encaminhamento de pacotes.
O primeiro encarregado de tomar as decises de roteamento, definindo a tabela de comutao para os roteadores. Este por sua vez transfere essas decises,
a tabela de comutao, por meio de uma API proprietria para o hardware de encaminhamento, que realiza a comutao dos pacotes ao nvel do hardware. A nica
interao de gerncia do usurio, no caso o administrador de rede, com o dispositivo,
24
Figura 3.1: Arquiteturas de roteadores: modelo atual e modelo programvel [40].

ocorre por meio de interfaces de configurao Web ou SNMP limitando-se ao uso de
funcionalidades bsicas programadas pelo fabricante.
Sendo a arquitetura atual definida por duas camadas autocontidas, no necessrio que elas sejam fechadas em um mesmo equipamento. A arquitetura das redes
SDN (Figura 3.1) subdivide essas camadas de forma que seja possvel programar remotamente o dispositivo de rede, permitindo que a camada de controle possa ser
movida para um servidor dedicado e com alta capacidade de processamento.
Desse modo, mantm-se o alto desempenho no encaminhamento dos pacotes
em hardware aliado flexibilidade de se inserir, remover fluxo de dados por meio de
aplicaes em software por meio de um protocolo aberto, API, para programao da
lgica do equipamento.
3.4
Elementos Programveis das redes SDN
De maneira mais especfica, os elementos de comutao, switches e roteadores,

exportam uma interface de programao que permite software de rede inspecionar,
definir e alterar a tabela de roteamento do comutador, isso acontece por exemplo
nos comutadores OpenFlow.
O software em questo, tende a ser na prtica organizado com base em controladores de aplicao geral, os Sistemas Operacionais de Rede, que controlam aplicaes especificas para a finalidade de cada rede. Outra possibilidade, e talvez uma
das mais interessantes desse paradigma, a capacidade de utilizar um divisor de
vises, como por exemplo o FlowVisor (discutido na Seo 3.5), que permite que as
aplicaes de rede sejam divididas entre diferentes controladores.
O principio bsico das Redes Definidas por Software a capacidade de programar
os elementos de uma rede de computadores. Essa programao a simples mani-
25
pulao dos pacotes em um fluxo. Esse fluxo geralmente definido em funo dos
recursos oferecidos pela interface de programao.
A maneira como os elementos de rede realizam a operao de encaminhamento
dos pacotes simples. Cada pacote recebido em uma das interfaces do comutador
de rede inspecionado e dele gerado uma consulta a uma tabela de encaminhamento do comutador. Atualmente nos switches Ethernet, essa consulta baseado no
endereo MAC de destino do pacote, em roteadores IP, em um prefixo do endereo
IP de destino.
Caso o comutador no encontre esse endereo na tabela de comutao, o pacote
descartado ou segue um comportamento padro, como por exemplo enviar ele a
todas as portas sadas do comutador (broadcast). Uma vez identificado o destino do
pacote, seja ele encontrado na consulta da tabela de comutao ou definido por um
comportamento padro, o mesmo atravessa as interconexes do comutador para
atingir a porta de destino, onde ela entra em uma fila para a transmisso.
Ao passar do tempo, com a evoluo das redes de computadores, o processo
de consulta (lookup) e chaveamento (switching) foi amplamente estudado no meio
acadmico, resultando hoje em solues baseadas usualmente em hardware com
desempenho suficiente para acompanhar as taxas de transmisso do meio [14].
Nesse sentindo as redes SDN tem a capacidade de controlar o plano de encaminhamento de pacotes por meio de uma interface bem definida. Sem dvida uma das
interfaces mais conhecidas deste paradigma, desde o inicio o OpenFlow. O principal objetivo do OpenFlow permitir que se utilize equipamentos de rede comerciais
para pesquisas de novos protocolos de rede em paralelo ao trfego real de produo
da rede.
Isso ocorre com os elementos de diviso de recursos, mais explicitados adiante, no
qual se define uma interface de programao que permite o desenvolvedor controlar
diretamente a tabela de encaminhamento dos comutadores de pacotes presentes na
rede. Esse tipo de proposta d mais credibilidade a pesquisa para a indstria, pois
as novas ideias sero validadas com o uso de comutadores de rede reais, de alto
processamento e utilizadas em redes reais que em geral contm grande fluxo de
dados.
Apesar do OpenFlow ser o foco principal do paradigma SDN, o paradigma no se
limita apenas ao OpenFlow e a forma como ele expe os recursos dos comutadores
de rede, nem o exige como elemento essencial. H diversas outras possibilidades
de implementao de uma interface de programao que atenda os objetivos do
paradigma.
Outra possibilidade de implementao o conceito de interface de rede sNICh [16].
O sNICh uma implementao para ambientes em redes virtualizadas em que a diviso do plano de dados feita de forma em que se possa dividir as tarefas de encaminhamento entre host e interface de rede. Com essa diviso garantido uma
eficincia no encaminhamento entre as mquinas virtuais no mesmo hospedeiro e a
rede.
Dessa forma possvel se imaginar uma interface definida para essa arquitetura
que possa ser usada para o controle de roteamento por um software implementado
em um controlador de rede, que se apresente como uma opo para o uso de comutadores de software como os switches OpenFlow.
26
Ainda possvel implementar outras propostas para o paradigma SDN que alteram a diviso de tarefas entre o controlador e os switches. Isso apresentado na
proposta de arquitetura do DevoFlow [15]. O DevoFlow aborda o argumento que o
OpenFlow muito dependente do controlador de rede SDN.
No OpenFlow existe a necessidade de que todos os fluxos sejam acessveis para
o controlador, isso por sua vez impe demandas sobre o hardware e limitaes de
desempenho que podem no ser aceitveis em casos particulares nos quais podem
ser definidos por regras simples.
Dessa forma, o DevoFlow reduz o nmero de casos em que o controlador precisa
ser acionado, aumentando a eficincia. Outras propostas de soluo podem ser aplicadas ao OpenFlow, basta que se faam regras especificas para cada fluxo que seja
identificado pelo controlador.
3.5
Divisores de Recursos
Uma das principais vantagens das Redes Definidas por Software so as diversas
formas de se dividir os recursos das redes. A possibilidade de se associar todo um
processamento complexo, definido por software, a pacotes que se encaixem em um
determinado padro abriu a possibilidade de se associar diversos comportamentos
em uma mesma rede [14].
Como dito no captulo anterior, essa possibilidade de diviso dos comportamentos
fez com que se tornasse vivel manter um comportamento tradicional para fluxos
reais de produo e um outro comportamento diferente para fluxos de pesquisa. O
primeiro trata-se do trfego real de produo de uma rede, o comportamento pode
seguir as orientaes do fabricante do hardware, ou mesmo dos roteadores legados
da rede. O segundo trata-se do trfego de pesquisa de novas solues de rede, a
possibilidade de realizar pesquisas em redes reais, no simuladas. de grande valia
para pesquisas, para novas solues em rede. A proposta do OpenFlow [42] parte
deste principio.
A capacidade de dividir a rede em fatias j ocorre na arquitetura atual da Internet
com a virtualizao de redes por meio do uso de VLANs (redes locais virtuais), em
que existe uma cabealho especial no pacote que usado para definir a qual rede
virtual ele pertence. O uso de VLANs no entanto tem suas limitaes definidas em
sua tecnologia de rede Ethernet, e por esse motivo torna-se complexo sua aplicao
em contextos nos quais essas fatias devam se estender por mais de uma tecnologia
de rede.
Considerando essa analogia do uso de VLANs com o contexto atual das redes SDN
possvel estender essa diviso de uma forma em que os recursos da rede sejam
virtualizados e apresentados de maneira isolada para cada desenvolvedor que deseje
ter o seu prprio controlador de rede.
Assim com a extenso dessa diviso, permitido que diferentes tipos de pesquisas possam ser colocadas em operao de forma paralela, na mesma rede fsica,
junto com o trfego de produo, bastando que sejam colocados elementos de diviso de viso na rede, efetuando a diviso dos recursos entre os diferente controladores de rede.
27
Isso evita que a rede fique restrita a um nico controlador abrindo espao para que
pesquisadores diferentes desenvolvam novos protocolos de rede usando tecnologias
diferentes em um mesmo ambiente de testes. Alm disso garante a no interferncia
entre as diversas aplicaes e permite a utilizao de diferentes interfaces SDN na
rede. A virtualizao pode ser implementada sobre uma rede fsica em diversos nveis
da mesma maneira que ocorre na virtualizao de mquinas fsicas.
A primeira soluo para a diviso de recursos nas redes SDN foi a diviso direta
dos recursos OpenFlow da rede fsica pelo FlowVisor [21]. O FlowVisor age como
um controlador de rede que tem a responsabilidade de dividir o espao de endereamento disponvel em uma rede OpenFlow. A diferenciao dessas fatias s possvel
graas as rotulaes dos pacotes definidas nos cabealhos do pacote. O comportamento dos elementos de comutao no paradigma SDN se baseia na consulta desse
campos.
Essa prtica nada mais do que uma extenso do principio de encaminhamento
do trfego da Internet atual, em que campos do endereo determinam direes no
grafo das redes de computadores. No FlowVisor esses diversos campos identificam
os fluxos OpenFlow(Figura 3.2) em que a definio dessas fatias constituem regras,
as quais definem as polticas de processamento.
Figura 3.2: Identificao dos fluxos OpenFlow pelo FlowVisor [20].

A Figura 3.2 mostra a definio das fatias com base nos trs atributos de fluxo,
o endereo IP, MAC e a porta TCP. Na figura o domnio bicasting handover define
o conjunto que corresponde a faixas do eixo de endereos IP e MAC. O domnio do
mobileVMs engloba todos os pacotes de todos os endereos IP e MAC mas com uma
faixa especifica de nmero de portas. J o hard handover corresponde a faixas do
conjunto de endereos IP e MAC com faixas do nmero de portas. Em outras palavras
o bicasting handover observa os eixos que correspondem os endereos IP e MAC. O
mobileVMs observa apenas o eixo das portas TCP. E finalmente o hard handover
observa os trs eixos do fluxo do grfico.
28
O FlowVisor se coloca entre os diversos elementos da rede. O comandos dos

controladores so analisados pelo FlowVisor para se certificar que as regras geradas
no excedam a definio do domnio do devido controlador. Isso serve para que
um pesquisador no se intrometa nas regras definidas por outros pesquisadores da
rede em outros fluxos da rede. Caso acontea uma exceo o FlowVisor reescreve os
padres utilizados com a definio do domnio.
Mensagens enviadas pelos comutadores OpenFlow so analisadas e direcionadas
para o controlador apropriado em funo do seu domnio. A Figura 3.3 apresenta esse
processo pelas duas vias de ida e volta. O comando de insero de uma regra (seta
continua) originado em uma aplicao do domnio A atravessa o FlowVisor, que por
sua vez, traduz a regra para garantir que ela se aplique apenas ao domnio de A.
Um pacote enviado por um switch OpenFlow para a sua aplicao (seta pontilhada)
processado pelo FlowVisor para a identificao do controlador responsvel daquela
faixa de domnio.
Figura 3.3: Fluxo de comandos do FlowVisor [14].

Ainda possvel criar uma topologia em que seja feita uma construo de hierarquias de FlowVisors cada um dividindo uma seo de um domnio definido por uma
instncia de um nvel anterior.
O FlowVisor apenas uma das maneiras possveis de se dividir os recursos em
uma Rede Definida por Software. Tambm possvel adotar um controlador para
dividir os recursos para outros controladores na rede. O conceito de virtualizao
tambm pode ser aplicado aos elementos de rede visveis para as aplicaes.
3.6
Controlador SDN
29
Sendo definida uma interface de programao dos comutadores de rede necessrio desenvolver uma aplicao que utilize essa interface para controlar cada
switch separadamente. Esse desenvolvimento trs consigo limitaes associadas ao
hardware de cada equipamento. Este desenvolvimento exige que o programador lide
com tarefas de baixo nvel no desenvolvimento de um software diretamente ligado a
um elemento de hardware ocasionando erros e aumentando a complexidade. Alm
disso novos desenvolvimentos exigem que todas as funcionalidades de baixo nvel
sejam reimplementadas.
Assim, faz-se necessrio um novo nvel na arquitetura das redes SDN, um nvel
que concentre as tarefas de manipulao dos elementos de rede oferecendo uma
abstrao de mais alto nvel para o desenvolvedor, fazendo uma analogia clara aos
sistemas operacionais de computadores pessoais (PCs). Essa a definio da natureza do paradigma de SDN.
Esse componente, chamado de sistema operacional de rede, ou melhor chamado de Controlador SDN, pode concentrar a comunicao com todos os elementos
programveis da rede oferecendo uma viso unificada da rede. Dessa forma possvel desenvolver programas que alm de ter uma viso centralizada da rede, com
anlises detalhadas, possvel tambm implementar novas funcionalidades para
chegar a decises operacionais de como o sistema deve operar [6], obtendo uma
melhor gerncia da rede.
Essa viso unificada da rede no necessariamente precisa ser centralizada. A
analogia que fazemos a sistemas operacionais distribudos podem ser implementado tambm nos controladores. A implementao pode der desenvolvida de forma
distribuda, seja pela diviso dos elementos de diferentes SAs ou por um controlador
realmente desenvolvido de forma distribuda com algoritmos que sejam capazes de
manter uma viso consistente entre suas partes.
Foram desenvolvidos diversos controladores para o paradigma SDN. Muitos dos
quais apresentam ambientes de tempo real de execuo que oferecem uma interface
imperativa para programao da rede. O que determina em grande parte o estilo de
desenvolvimento e as funcionalidades que o controlador oferece a linguagem de
programao em que ele foi desenvolvido seja ele em C, Java, Python, Ruby entre
outros.
H, no entanto, outros controladores que ultrapassam a noo de uma interface
de programao propriamente dito, e utilizam abstraes com um ambiente de programao funcional ou declarativo. Nesse caso as implementaes do controlador
se prestam as funcionalidades de deteco do conflitos ou depurao da rede.
Muitos dos controladores j desenvolvidos no se preocupam com requisitos de
escalabilidade e disponibilidade da rede optando assim por estruturas centralizadas
por pura simplicidade. No entanto, h desenvolvimentos voltados para a implementao de grandes sistema de redes nos quais utilizam-se diferentes formas de distribuio de controle para garantir requisitos como escalabilidade e disponibilidade
do sistema. Essa seo apresenta alguns controladores SDNs desenvolvidos, sendo
apresentado suas caractersticas principais. A Figura 3.4 apresenta uma tabela comparativa dos principais controladores SDN.
30
Nome
Linguagem
Plataforma
Caracterstica
NOX
C++, Python
Linux
Controlador de referncia
OpenFlow
POX
C++, Python
Windows, Mac, Linux
Evoluo do NOX
Maestro
Java
Windows, Mac, Linux
Explora o paralelismo
Beacon
Java
Windows, Mac, Linux,

Android
Floodlight
Java
Windows, Mac, Linux
Frenetic
Funcional/Declarativa
Prpria
Linux
Onix
C++, Python, Java
Windows, Mac, Linux
SNAC
C++
Linux
Multiplataforma,
Multithreaded
Pode-se integrar a redes
no OpenFlow
Programa a rede como um
todo
Gerncia redes de grande
porte
Monitoramento de redes
OpenFlow; Interface Web
Trema
C, Ruby
Linux
Script; Emulador
Figura 3.4: Principais controladores SDN.
3.6.1
NOX
O NOX [18] o controlador de referncia que acompanha o OpenFlow, contm

APIs desenvolvidas em C++ e Python. O NOX serve como uma camada de abstrao
criando as aplicaes e servios que gerenciam as entradas de fluxo nos switches
OpenFlow. Seu funcionamento dar-se da seguinte maneira: se o pacote no possui
nenhuma entrada da tabela de fluxos o mesmo encaminhado ao NOX, normalmente
o primeiro pacote de cada fluxo enviado ao controlador, este por sua vez checa e
procura uma regra determinando a poltica a ser aplicada.
Dependendo da aplicao pode-se determinar uma regra padro como por exemplo: optar por enviar todos os pacotes de determinados fluxos ao controlador. Uma
aplicao de DHCP seria um bom exemplo j que o fluxo desta aplicao no precisa
ser adicionado na tabela.
O NOX oferece uma interface de programao na qual para se desenvolver ou implementar uma nova soluo de rede dois conceitos so utilizados, o componente e
o evento. O componente um encapsulamento de funcionalidades que so carregadas com o NOX, um firewall por exemplo pode ser implementado como um componente e agregado ao NOX. Os componentes podem ser escritos em C++ ou Python.
Um evento uma ao realizada sobre um determinado fluxo. As aplicaes implementadas no NOX utilizam um conjunto de manipuladores que so registados para
serem executados quando um evento especfico acontece [18].
Os eventos so gerenciados por mensagens OpenFlow por meio de pacotes recebidos de um switch na rede. Quando um switch envia um pacote para o controlador
NOX por meio do protocolo OpenFlow, este analisado pelo controlador e dispara
um evento de acordo com a poltica determinada pela aplicao.
31
A grande maioria dos projetos de pesquisa na rea de Redes Definias por Software so baseados no controlador NOX, que um controlador simples para redes
que prov primitivas para o gerenciamento de eventos bem como as funes para a
comunicao com os switches [18]. Entretanto seu desenvolvimento foi descontinuado, dando lugar ao POX.
3.6.2
POX
O POX o irmo mais novo do NOX. Sua essncia uma plataforma para o desenvolvimento e a prototipagem rpida de aplicaes de software para redes SDN
usando Python.
O POX est em constante desenvolvimento e tm o objetivo de substituir o NOX.
Sua arquitetura, baseada no NOX, mais estvel e sua interface mais elegante
resultando em um controlador mais moderno e simples.
Embora o POX seja mais estvel, o NOX ainda permanece como um ambiente
adequado para implementaes que tenha demandas mais elevadas em termos de
desempenho. No entanto os desenvolvedores do POX acreditam que este seja mais
adequado para substituir o NOX nos casos em que Python utilizado. Este controlador
ser discutido em destaque no captulo 5.
3.6.3
Maestro
O Maestro [4] outro controlador de rede do paradigma SDN para switches OpenFlow. O Maestro foi desenvolvido em JAVA e tem como objetivo orquestrar aplicaes
de controle por meio de interfaces que acessam e modificam o estado da rede coordenando suas interaes.
O modelo de programao do Maestro oferece: interfaces para a introduo de
novas funes de controle personalizadas; interfaces para a manuteno do estado
da rede; e componentes de controle para a especificao da sequncia de execuo
dos componentes da rede.
O Maestro explora o paralelismo de uma mquina ao mximo para obter um maior
desempenho do sistema de transferncia entre o controlador e o switch, visto que
o controlador pode ser um gargalo devido a responsabilidade da criao de cada
fluxo de dados entre os switches. O Maestro alivia o esforo que os programadores
tm para realizar a paralelizao do sistema operacional de rede, trazendo assim um
maior desempenho no controle da rede e diminuindo esse gargalo.
3.6.4
Beacon
O Beacon [12] mais um controlador baseado em JAVA que suporta tanto operaes de controle baseadas em eventos quanto operaes baseadas em threads.
O projeto vem sendo desenvolvido desde agosto de 2011 na Universidade de
Stanford. Suas principais caractersticas so:
tem uma implementao estvel, consegue gerenciar 100 switches virtuais e
20 fsicos em redes experimentais por meses sem inatividade;
32
multi-plataforma, por ser desenvolvido em JAVA;

software livre baseado em licena GPL v.2;
tem um rpido desempenho por ser multithreaded;
O Beacon contm uma estrutura que permite que o controlador seja atualizado
em tempo de execuo sem interromper outras atividades de encaminhamento de
pacotes.
3.6.5
Floodlight
O Floodlight [24] um projeto que se originou do controlador Beacon e agora

apoiado pela Open Networking Foundation (ONF) e tambm pela Big Switch Networks1 ,
que produz controladores comerciais que suportam o Floodlight.
O Floodlight totalmente baseado na linguagem JAVA com seu ncleo e mdulos
principais escritos em JAVA, recentemente foi adicionando o Jython, o que permite o
desenvolvimento na linguagem Python. Ele distribudo segundo a licena Apache
permitindo que o administrador de rede possa utiliz-lo para praticamente qualquer
finalidade. Alm disso o projeto est sendo desenvolvido por uma comunidade aberta
na qual todos podem participar. Sua documentao, status sobre o projeto, roteiro e
erros esto todos disponveis.
Sua arquitetura formada por mdulos que exportam servios. Dessa forma toda
a comunicao entre os mdulos feita por meio de servios. Sua interface permite
identificar e descobrir o status e a topologia de uma rede automaticamente. Outra
caracterstica importante do Floodlight que com ele pode se integrar redes no
OpenFlow e tambm compatvel com a ferramenta de simulao MiniNet.
3.6.6
Frenetic
O Frenetic [25] um sistema de rede baseado em linguagem funcional desenvolvido para operar em redes OpenFlow. Em geral os controladores especificam a
poltica de encaminhamento nos switches OpenFlow uma de cada vez. O Ele permite
que o operador da rede, ao invs de configurar manualmente cada switch da rede,
programe a rede como um todo.
O Frenetic implementado sobre o NOX, foi projetado para resolver os problemas
de programao com o OpenFlow utilizando o controlador NOX. Alm disso introduz
abstraes funcionais para permitir aplicaes modulares e a composio dessas
aplicaes.
O Frenetic composto de duas sublinguagens integradas, sendo uma linguagem
do tipo declarativa para consultas de classificao e agregao de trfego na rede,
e outra linguagem funcional para descrever as polticas de encaminhamento de pacotes em alto nvel para toda a rede.
1
http://www.bigswitch.com
33
3.6.7
Onix
O Onix [22] um controlador que tem o objetivo de gerenciar redes de grande

porte de maneira distribuda. O Onix um sistema operacional distribudo de rede
que prov abstraes para particionar e distribuir o estado da rede em mltiplos
controladores distribudos garantindo problemas de escalabilidade e disponibilidade
que podem surgir quando um controlador centralizado utilizado.
A rede mantida por meio de uma estrutura de dados que representa um grafo
com todos os elementos da rede fsica. por meio desta estrutura que a viso global do sistema constituda sendo a base do modelo de distribuio do Onix. As
interfaces de controle da rede so implementadas por meio de operaes de leitura
e atualizao do estado dessa estrutura de dados garantindo assim a escalabilidade
e disponibilidade da rede por meio do particionamento e da replicao da estrutura
entre diversos os servidores do sistema.
O resultado do sistema mostra um bom desempenho em relao a escalabilidade
da rede apresentada atendendo os requisitos do projeto em questo. O Onix um
produto fechado e portanto um controlador proprietrio.
3.6.8
SNAC
O SNAC [41], ou Simple Network Access Control um controlador de monitoramento de redes OpenFlow. Sua interface baseada em uma ferramenta web que
mostra os status e as caractersticas da rede. Ele incorpora uma linguagem de definio de poltica flexvel com uma interface de fcil utilizao para configurar dispositivos e eventos da rede.
Todas as suas funcionalidades so agrupadas em categorias disponveis na interface web na qual possvel se monitorar as tarefas do dia-a-dia das polticas de
controle da rede. possvel ver os status do sistema e gerenciar as polticas de segurana da rede permitindo um acesso rpido a qualquer pgina dentro do sistema. A
maioria das pginas so atualizadas automaticamente para manter as informaes
exibidas de acordo com o estado interno das polticas de controle da rede.
Apesar do SNAC ter um bom controle de gerenciamento e monitoramento grfico
de uma rede OpenFlow ele no um ambiente de programao genrico como os
outros controladores apresentados.
3.6.9
Trema
O Trema [45] uma aplicao OpenFlow para o desenvolvimento de controladores. Ele utiliza as linguagens de programao Ruby e C para que pesquisadores desenvolvam e criem de maneira fcil seus prprios controladores OpenFlow. O Trema
no tem como objetivo fornecer uma implementao especfica como controlador,
seu objetivo ajudar desenvolvedores a criarem implementaes por meio de scripts
simples escritos em Ruby ou C.
O Trema ainda possui um emulador de rede OpenFlow prprio para a execuo
de testes. No necessrio switches e hosts fsicos, nem ambientes virtuais como o
MiniNet, para testar aplicaes para o controlador desenvolvido.
34
3.7
Aplicaes
Seguindo o presente contexto, considerando agora os controladores do paradigma SDN como sistemas operacionais de rede, o software desenvolvido para criar
novas funcionalidade pode ser visto como uma aplicao que executada sobre uma
rede fsica.
Dessa forma, observando agora a rede como um sistema unificado e gerenciado por um sistema operacional, pode-se, por exemplo, implementar solues de
roteamento e de encaminhamento especialmente desenhadas para ambientes particulares, controlando as interaes entre os diversos comutadores da rede.
Essa tamanha flexibilidade que este paradigma oferece para se estruturar sistemas de rede til em praticamente todas as reas de aplicao das redes de
computadores. Sua estrutura lgica centralizada permite o desenvolvimento de novas funcionalidades de maneira fcil e bem diversificada, abrangendo assim uma
grande diversidade de ambientes de rede. Considerando que as redes SDN definem
essa nova forma de estrutura, podemos considerar que ela seja aplicvel a qualquer
tipo de ambiente no cenrio de redes de computadores nos beneficiando de uma
melhor organizao das funcionalidades oferecidas em torno de uma viso lgica
completa da rede.
Essa seo aborda os principais contextos em que podemos nos beneficiar com
essa estrutura de rede, apresentando exemplos e maneiras de como podemos utilizar
essas aplicaes em diversos casos.
3.7.1
Controle de Acesso
Uma das principais caractersticas do paradigma SDN consiste no tratamento dos

pacotes por meio de padres que identificam seus fluxos. Nesse sentido o desenvolvimento de aplicaes que gerenciam o controle de acesso bastante trivial nesse
paradigma.
A viso lgica global que o paradigma SDN nos trs permite a configurao de
polticas de controle de acesso que sejam desenvolvidas com base em informaes
abrangentes, diferentemente do que ocorre nas redes atuais, em que o controle de
acesso definido, por exemplo, seguindo um poltica de firewall em um enlace especifico da rede.
Alm disso essa viso lgica global da rede nos permite implementar regras que
levem em conta no apenas tipos de protocolo e pontos de origem e destino dos pacotes, mas a relao entre dois pontos distintos da rede e a identidade do usurio de
forma simples. A facilidade de se definir qual rota adotar em cada fluxo nos permite
criar filtros especiais para o controle de acesso de determinados tipos de trfego em
determinados elementos da rede.
3.7.2
Gerenciamento de Redes
Como o estado da rede pode agora ser centralizada em um controlador, as decises sobre a forma de fluxos de determinadas rotas podem ser mudadas dinami35
camente com base na preferncia do operador e gerenciada centralmente por meio

deste controlador. A viso global da rede simplificam as aes de configurao e
gerncia da rede.
Nas redes de computadores atuais o gerenciamento realizado por configuraes de baixo nvel que depende do conhecimento da rede, semelhante ao desenvolvimento de aplicaes sem ajuda do sistema operacional. Podemos exemplificar
o controle de acesso aos usurios de uma rede utilizando uma ACL (Access Control
List) que consiste em uma lista de controle de acesso que necessita do conhecimento
do endereo IP do usurio, que um parmetro de baixo nvel independentemente
da rede.
Nesse sentido, analogamente ao desenvolvimento de aplicaes utilizando um
sistema operacional, com o paradigma SDN e a utilizao de um sistema operacional
de rede torna-se mais fcil o gerenciamento das redes de computadores por meio de
interfaces de alto nvel para controlar e observar a rede, semelhante s interfaces
de leitura e escrita em diversos recursos oferecidos por um sistema de computador.
Dessa forma os sistemas operacionais de rede fornecem interfaces genricas de
programao que permitem o desenvolvimento de aplicaes de gerenciamento das
redes, centralizando o gerenciamento da rede e resolvendo os problemas advindos
da escalabilidade, diferentemente do que ocorre nas redes de computadores atuais.
3.7.3
Gerenciamento de Energia
O gerenciamento de energia tambm um dos pontos fortes que podemos obter

de maneira fcil com o paradigma SDN. Atualmente as solues que conservam e gerenciam energia em sistemas da computao vem crescendo bastante. Em redes de
grande porte, onde os recursos de rede consomem uma parcela significativa do gasto
de energia, reduzir o consumo de energia consumida pelo meio de comunicao se
torna uma possibilidade interessante.
Em determinados perodos do dia alguns elementos da rede ficam subutilizados
devido ao baixo fluxo de dados na rede. O desligamento desses dispositivos de rede
tornam-se viveis devido a baixa taxa de transmisso dos mesmos provocando a
reduo do consumo de energia nessa rede.
Isso possvel devido a caracterstica da viso global da rede que provida pelo
paradigma SDN. Uma vez tendo essa viso global da rede torna-se fcil a identificao desses elementos ociosos e mesmo a redefinio de rotas a fim de desviar o
trfego de elementos passveis de desligamento. Alm disso o uso do controle de rotas de deciso permite a implementao de pontos de controle que podem interceptar trfego ruidoso na rede, evitando que pacotes de menor importncia atinjam
o elementos subutilizados passveis de deligamento, evitando que os mesmo sejam
ativados desnecessariamente.
3.7.4
Comutador Virtual Distribudo
Virtualizao de redes hoje bastante utilizada em redes corporativas e em redes

de grande porte. Usualmente so utilizados switches implementados por software
36
instalado em cada mquina fsica a fim de prover a conectividade exigida por cada
mquina virtual.
A facilidade de mover as mquinas virtuais entre os hospedeiros fsicos torna o
processo de configurao e monitorao dessas mquinas um desafio que complica
a gerncia dos switches virtuais [14]. Uma maneira possvel para reduzir essa complexidade o uso do paradigma SDN. A ideia oferecer uma viso de um switch
nico, virtual a todas as mquinas virtuais da rede de maneira que oferea a elas a
impresso de estarem ligadas a um nico switch. Dessa forma a migrao das mquinas virtuais entre os hospedeiros fsicos seria simples e teria um impacto minimo
nas configuraes da rede virtual pois elas continuariam ligadas a mesma porta do
nico switch visvel para toda a rede.
Essa abstrao pode ser implementada de maneira muito simples com um controlador de rede, por exemplo o NOX, j que ele poderia inserir automaticamente as
regras de encaminhamento de pacotes entre as portas dos diversos switches criando
o efeito desejado. Com o uso de switches fsicos OpenFlow tambm possvel fazer
com que mquinas fsicas, no virtualizadas, possam fazer parte desta rede.
3.7.5
Redes Domsticas
As redes domiciliares vem sendo consideradas um dos grandes desafios para a

indstria de redes de computadores, de modo especial no que se refere ao uso de ferramentas eficientes para sua gerncia e configurao [13]. Esse investimento exige
tanto solues que resolvam a interao com o usurio quanto solues eficiente
para automao de configurao e implementao de polticas de segurana para o
lar.
Uma maneira de utilizar aplicaes SDNs nesse contexto seria o uso de roteadores
domsticos OpenFlow com o provedor de acesso tendo a responsabilidade de poder
controlar a rede por meio de um controlador SDN. Dessa maneira o controlador SDN
seria capaz de programar, alterando suas polticas e regras de controle em cada
roteador domstico. Com essa possibilidade o provedor de acesso poderia gerir as
regras de acesso apropriadas para cada tipo de usurio, alm claro de ter uma viso
global da rede como um todo, gerenciando elementos subutilizados e priorizando
elementos com mais trfego na rede.
Outra possibilidade que aborda esse contexto so as pesquisas que gerenciam o
trfego licito e ilcito nas redes de computadores [5, 23]. Se os provedores de acesso
puderem obter a viso global de todos os seus usurios na rede ele capaz de indicar
quais padres de trfego so as aes de atacantes (crackers) ou cdigo malicioso
melhorando assim a segurana nas redes de computadores.
Claro que essas possibilidades exigem um forte investimento na infraestrutura da
rede, visto que o protocolo OpenFlow exige a substituio dos equipamentos de rede,
alm, claro, de ser necessrio um canal seguro (SSL) entre os roteadores OpenFlow
e o controlador SDN, aumentando ainda mais o gasto em infraestrutura. No entanto
essas possibilidades, embora no sejam viveis (ainda), podem ser consideradas o
futuro das redes de computadores.
Ainda h outros tipos de solues domiciliares que podemos usar com o paradigma SDN, podemos considerar a implementao de um controlador de rede interno
37
rede domiciliar. Esse tipo de soluo se torna interessante quando observamos o

aumento da complexidade das rede domsticas nos dias atuais. As redes domiciliares contam hoje com diversos equipamentos que funcionam com a Internet, desde
celulares, notebooks a eletrodomsticos, sejam eles conectados por enlaces com fio
ou sem fio.
Com um controlador domstico um usurio poderia observar todo o trfego interno da rede domstica, podendo gerenciar o uso de banda em cada equipamento
de rede, configurando os servios da rede tais como impressoras e novos dispositivos
de acesso, alm claro de observar e detectar potenciais mquinas infectadas por
malware.
3.7.6
Roteador Expansvel de Alta Capacidade
As redes de computadores mais robustas possuem em suas bordas elevadas demandas de conectividade. Com isso faz-se necessrio o uso de roteadores de grande
porte para que suportem essas demandas, entretanto tais roteadores possuem um
custo bastante elevado.
Com o paradigma SDN, possvel substituir esse roteador de grande porte por
uma banco de switches de mdio porte desde que estes sejam dotados de interfaces OpenFlow. Dessa forma, semelhante ao que ocorre no caso do comutador virtual
distribudo, um controlador SDN pode preencher as tabelas de roteamento de cada
switch com as rotas necessrias para interligar o trfego entre duas portas de switches diferentes que sejam vistas como parte de um mesmo roteador [14].
Todas as informaes de roteamento seriam distribudas entre os switches pelo
controlador em funo das demandas identificadas. Os algoritmos de roteamento do
roteador poderiam tambm ser executados pelos controladores, que se encarregaria
de manter a interface com os demais roteadores externos de outras redes.
3.7.7
Redes de Grande Porte
Nas redes de grande porte em que existem aplicaes de vrios usurios, um problema sempre recorrente o isolamento do trfego entre essas diversas aplicaes.
O problema hoje resolvido com a utilizao de VLANs individuais para cada cliente.
Dessa forma o trfego gerado pelas aplicaes de cada usurio transportado apenas dentro da sua VLAN, garantindo o isolamento necessrio para fins de segurana
e privacidade.
Todavia, os recursos de VLANs so limitadas pelo tamanho dos campos utilizados para sua identificao, tornando invivel sua utilizao em redes que possuem
um grande numero de usurios. Outro problema que as interfaces de configurao e gerncia desses tipos de rede so bastante complexas dificultando bastante o
controle da rede.
Uma maneira de solucionar esse problema a utilizao de uma abstrao de
um comutador virtual distribudo por meio de um controlador SDN. Dessa forma
fornecido a cada usurio um switch virtual que ir interligar suas mquinas independentemente da localizao fsica na rede. O controlador fica ento responsvel
38
por definir as rotas entre as portas dos diversos elementos que compe o comutador virtual garantindo a alocao de recursos suficientes em cada caso. Pelo fato de
cada usurio estar conectado a um switch virtual diferente, o isolamento do trfego
garantido diretamente pela implementao da rede SDN.
Outra consequncia desse tipo de isolamento de trfego alm de eficaz e ilimitado
que existe a possibilidade de se oferecer a cada usurio o controle direto de sua
rede. As configuraes que estejam disponveis para o switch virtual podem ser
controladas pelo o usurio j que elas no iro influenciar as outras redes por estarem
isoladas das demais. Solues como balanceamento de carga, qualidade de servio
e redundncia de rotas podem ser colocadas sob o controle do usurio desde que o
controlador de rede garanta esse tipo de implementao no switch virtual.
39
Captulo 4
OpenFlow
Observamos nos captulos anteriores que as redes de computadores atuais j no
atendem requisitos atuais da Internet e para que esses requisitos sejam atendidos
foram apresentadas algumas propostas para a Internet do Futuro. Uma das propostas
mais promissoras que vm ganhando destaque no meio acadmico so as Redes
Definidas por Software (Software Defined Networks, (SDN)).
As redes SDN constituem um novo paradigma para o desenvolvimento das redes
de computadores abrindo novas perspectivas em ambientes de controle lgico da
rede de maneira que possam ser desenvolvidas de forma simples e livres dos limites
da arquitetura atual da rede.
Nesse contexto as redes SDN trazem consigo a capacidade de controlar o plano de
encaminhamento dos pacotes da rede, no entanto para que isso ocorra necessrio
uma interface que seja simples para realizar a comunicao entre os elementos de
comutao da rede e o controlador da rede. De fato a interface que foi associada
desde o inicio ao paradigma SDN, sendo um dos elementos mais motivadores para
sua criao, foi o OpenFlow.
O OpenFlow [19] foi proposto pela Universidade de Stanford, seu objetivo inicial
atender demanda de validao de novas propostas de arquitetura e protocolos
de rede sobre equipamentos comerciais. Dessa forma possvel implementar uma
tecnologia capaz de promover a inovao no ncleo da rede, por meio da execuo
de redes de teste em paralelo com as redes de produo.
A proposta do OpenFlow promove a criao de redes SDN, usando elementos
comuns de rede, tais como switches, roteadores, pontos de acesso ou, at mesmo,
computadores pessoais1 [19].
Este captulo apresenta as caractersticas do padro OpenFlow, bem como os
elementos necessrios para sua configurao e aplicao em uma Rede Definida por
Software. Tambm apresentado o comutador OpenFlow, suas caractersticas, seu
funcionamento e como utilizado entre os comutadores OpenFlow e um controlador
SDN.
1
Uma das maneiras de se implementar um comutador OpenFlow em computadores pessoais

com o Open vSwitch [38], seu funcionamento se baseia em um mdulo do Linux que implementa o
encaminhamento programvel de pacotes diretamente no kernel do sistema, seu plano de controle
acessado a partir do espao de usurio.
40
4.1
Pradro OpenFlow
O OpenFlow um padro aberto para o paradigma de redes SDN, ele consiste de

uma interface de programao que permite ao desenvolvedor controlar diretamente
os elementos de encaminhamento de pacotes presentes no dispositivo.
A pesquisa na rea de redes de computadores possui diversos desafios em relao a implementao e a experimentao de novas propostas de rede em ambientes
reais. O pesquisador de redes em geral no possui uma rede de teste que apresente
desempenho prximo de uma rede real. Para isso foi proposto o OpenFlow que permite que um pesquisador possa experimentar suas propostas em redes reais, sem
atrapalhar o fluxo de produo, obtendo uma melhor validao na sua pesquisa para
a indstria.
O OpenFlow consiste de um mecanismo que executado em todos os comutadores da rede para que haja o isolamento do trfego de produo e o trfego experimental. Dessa forma os pesquisadores podem reprogramar os comutadores de
maneira que no haja interferncia no trfego de produo, ou seja, a rede continuar funcionando da mesma forma.
Outro objetivo da proposta do OpenFlow permitir que os fabricantes de hardware possam inserir as funcionalidades do OpenFlow nos seus comutadores sem a
necessidade de expor o projeto desses equipamentos. Um requisito importante nessa
abordagem, j que a infraestrutura ser modificada, que tais equipamentos devem
possuir um custo baixo e um desempenho semelhante aos j utilizados na rede de
produo, de maneira que se torne vivel para os administradores de rede a troca
desses equipamentos pelos j utilizados.
O projeto do OpenFlow tem por objetivo ser flexvel e atender o seguinte requisitos
estipulados:
capacitar o uso em implementao de baixo custo e alto desempenho;
possibilitar o suporte de uma vasta gama de pesquisas cientficas;
garantir o isolamento do trfego de produo e o trfego experimental;
garantir que no seja necessrio a exposio do projeto dos fabricantes em
suas plataformas.
Uma das caractersticas bsicas do padro OpenFlow a separao clara entre
os planos de dados e de controle nos elementos de comutao. O plano de dados
responsvel pelo encaminhamento dos pacotes associando entradas na tabela de
encaminhamento de cada comutador, essas regras so definidas pelo padro e incluem os seguintes itens como tomada de ao:
encaminhar o pacote para uma porta especifica do dispositivo;
alterar parte de seus cabealhos;
descartar o pacote;
encaminhar o pacote para a anlise de um controlador de rede.
41
necessrio deixar claro que o plano de dados pode ser implementado em hardware utilizando elementos comuns a roteadores e switches atuais. Em geral essa
estrutura se configura em dispositivos dedicados que tenha a interface de configurao OpenFlow, por exemplo, comutadores de uma rede de produo que se queira
fazer testes experimentais de pesquisas de rede.
Por outro lado o plano de controle fica responsvel pelo controle da rede permitindo ao controlador SDN da rede programar as entradas dessa tabela de encaminhamento com padres que identificam fluxos de interesse e as regras associadas
a eles. O elemento responsvel pelo plano de controle pode ser um mdulo em
software implementado de forma independente em algum ponto da rede. Esse elemento, denominado controlador SDN, fica responsvel por instalar regras e aes no
hardware de rede.
4.2
Componentes de uma Rede OpenFlow
Para que uma rede programvel com OpenFlow exista necessrio que sua arquitetura seja composta por quatro componentes a ela associados. necessrio
equipamentos habilitados que tenham a capacidade de alterar suas tabelas de encaminhamento conforme as decises de um controlador em software a eles conectados
por de um canal seguro.
Tabela de Fluxos - Cada entrada na tabela de fluxos do hardware de rede composta por regras, aes e controles de estatstica. A regra formada pela definio dos valores de um ou mais campos do cabealho do pacote, por meio
dela que determinado o fluxo. As aes ento ficam associadas ao fluxo e
vo determinar como os pacotes devem ser processados, para onde vo ser
encaminhados ou se sero descartados. Os controles de estatstica consistem
de contadores utilizados para manter estatsticas de utilizao e para remover
fluxos inativos ou que no existam mais. Logo, as entradas da tabela de fluxos
so interpretadas pelo hardware como decises em cache do plano de controle
em software, sendo, portanto, a mnima unidade de informao no plano de
dados da rede [40].
Protocolo OpenFlow - o protocolo para a comunicao entre o comutador OpenFlow e o controlador de rede para que haja a troca de mensagens por um canal
seguro. Essas mensagens podem ser simtricas, assncronas ou ainda iniciadas
pelo controlador [42].
Controlador - O controlador, fica responsvel por tomar as decises adicionando e
removendo entradas na tabela de fluxos de acordo com uma poltica de encaminhamento. O controlador uma camada de abstrao da infraestrutura fsica
que tem como objetivo facilitar o desenvolvimento de aplicaes e servios que
gerenciam as entradas de fluxo na rede. Como j dito, esse modelo de abstrao se assemelha ao outros sistemas de software que provm a abstrao do
42
hardware como, por exemplo, os sistemas operacionais de computadores pessoais. Esse modelo permite a evoluo em paralelo das tecnologias no plano
de dados e as inovaes na lgica das aplicaes de controle.
Canal Seguro - Este elemento no s garante que uma rede SDN no sofra ataques
de elementos mal intencionados como garante tambm que a troca de informaes entre os comutadores e controladores da rede sejam confiveis com baixa
taxa de erros. A interface de acesso que o projeto do OpenFlow recomenda
o SSL (Secure Socket Layer), no entanto existem outras alternativas como o
TCP e o PCAP (packet capture) sendo muito teis em ambiente virtuais e de
experimentao por sua simplicidade de utilizao.
A Figura 4.1 mostra a arquitetura de uma rede OpenFlow. Os comutadores OpenFlow se comunicam com o controlador por meio do protocolo OpenFlow em um canal
seguro. O controlador adiciona ou remove entradas nas tabelas de fluxos dos comutadores de acordo com as aplicaes de controle de cada rede virtual.
Figura 4.1: Componentes de uma rede OpenFlow [33].
4.3
Protocolo OpenFlow
Uma das vantagens em se utilizar uma arquitetura OpenFlow a flexibilidade

que ela oferece para se programar de forma independente o tratamento de cada
fluxo da rede e como ele deve ou no ser encaminhado pela rede. De uma maneira
mais prtica o OpenFlow determina como um fluxo pode ser definido, quais sero as
aes que podem ser realizadas para cada pacote pertencente a este fluxo e qual
o protocolo de comunicao entre o controlador e os comutadores utilizados para
realizar as definies de fluxo e aes.
43
Dessa forma uma entrada na tabela de fluxos de um comutador OpenFlow formada pela unio da definio do fluxo e um conjunto de aes a ele determinadas.
Um fluxo constitudo pela definio dos valores de um ou mais campos do cabealho do pacote a ser processado pelo dispositivo OpenFlow. Dessa forma os campos
do cabealho descrevem o fluxo que por sua vez descrevem quais pacotes combinam com aquele fluxo. Esses campos formam uma tupla de doze elementos que
rene caractersticas dos protocolos da camada de enlace, de rede, e de transporte
segundo o modelo TCP/IP. Cada fluxo contm regras, para a definio dos pacotes,
aes e contadores estatsticos a ele associados, como pode ser visto na Figura4.2.
Regras
Aes
Estatsticas
Pacotes; Bytes; Durao do Fluxo
Encaminhar Pacotes
Enviar pacotes para o controlador
Processo normal do dispositivo
Alterar campos
Descartar pacote
....
Figura 4.2: Definio de um fluxo na arquitetura OpenFlow [19].

Nesse contexto com a definio de fluxo, possvel observar que as regras de
encaminhamento de um pacote no se restringem ao endereo IP ou endereo MAC
dos pacotes. O protocolo OpenFlow mais abrangente de maneira que os elementos
formados pelos campos do pacote, as tuplas, podem conter valores exatos ou valores
arbitrrios, que combinam com qualquer valor que o pacote comparado apresente
para o campo. O encaminhamento pode se dar por outras caractersticas do pacote,
como por exemplo, as portas de origem e destino do protocolo de transporte. Essas caractersticas descrevem o funcionamento do protocolo OpenFlow explicitados
adiante.
4.4
Controlador OpenFlow
44
O controlador OpenFlow segue praticamente as mesmas caractersticas dos controladores SDN apresentados no capitulo anterior. Ele consiste de um controle centralizado, seja fisicamente ou logicamente, que executa aplicaes de controle sobre
a rede OpenFlow configurando e gerenciando as tabelas de fluxo dos elementos encaminhadores.
obviamente necessrio que o controlador implemente o protocolo OpenFlow
para se comunicar, por meio de mensagens, com os elementos encaminhadores (comutadores com OpenFlow habilitado), enviando os comando para a rede. O controlador age como um sistema operacional de rede agindo sobre o plano de controle
como uma interface entre as aplicaes de controle da rede e a prpria rede.
As mensagens enviadas pelo controlador podem ou no necessitar de resposta
do elemento encaminhador e so classificadas de acordo com os seguintes tipos:
Mensagens de caractersticas - Geralmente ocorrida aps o estabelecimento do
canal entre o comutador e o controlador OpenFlow, o controlador solicita ao
comutador o pedido de conexo, bem como as caracteristicas especificas e as
capacidades do mesmo para que o controlador possa gerenciar melhor a rede.
Mensagens de configuraes - O controlador capaz de definir e consultar parmetros de configurao no comutador. O comutador responde a solicitao de
consulta do controlador.
Mensagens de modificaes do estado - So mensagens enviadas pelo controlador para gerenciar os estados dos comutadores. Seu principal objetivo adicionar ou remover entradas nas tabelas de fluxo dos comutadores, ou seja,
adicionar e remover regras.
Mensagens de leitura do estado - So mensagens enviadas pelo controlador para
ler os status e coletar as estatsticas (contadores) do controlador.
Mensagens de packet-out - Essas mensagens so usadas para enviar pacotes
completos para o comutador. Quando no h uma correspondncia entre o
pacote e alguma entrada na tabela de fluxos do comutador, o pacote ento
encaminhado, por completo, para o controlador (Parcket-In), que este por
sua vez reenvia, utilizando o Packet-out, o mesmo pacote com seu conjunto de
aes a ele associado.
Mensagens de barreira - So mensagens utilizadas pelo controlador para garantir
se a dependncias de mensagens foram cumpridas ou para receber notificaes
de operaes concludas.
4.5
Funcionamento
Definido o protocolo e o controlador OpenFlow o funcionamento de uma rede

OpenFlow programado a partir do plano de controle. Os fluxos podem ser definidos
da forma escolhida pelo controlador, como por exemplo, todos os pacotes enviados
45
pela mquina com IP X para a maquina com IP Y ou, ainda, todos os pacotes
pertencentes a VLAN Z. As aes so definidas a partir destes fluxos e incluem:
(a) encaminhar os pacotes pertencentes quele fluxo para determinada(s) porta(s);
(b) enviar os pacotes para o controlador;
(c) descartar o pacote como medida de segurana;
(d) modificar os campos dos cabealhos dos pacotes;
(e) encaminhar o pacote para o processamento normal do dispositivo.
As aes do ltimo tipo (e) garantem que o trfego experimental no interfira no
trfego de produo da rede. Outra maneira de garantir isso definindo um conjunto
de VLANs para fins experimentais. Com essa separao dos trfegos possvel ter
equipamentos hbridos que processam trfego legado de acordo com os protocolos
e as funcionalidades embarcadas do equipamento e, ao mesmo tempo, de maneira
isolada, obtm o trfego baseado nas regras do OpenFlow. As aes associadas aos
fluxos formam as entradas nas tabelas de fluxo do comutador OpenFlow.
Alm das aes, a arquitetura OpenFlow tambm possui contadores para o controle de cada fluxo. Cada fluxo contm contadores para o controle de: nmero de
pacotes; nmeros de bytes trafegados no fluxo; e durao do fluxo. Esses contadores
so implementados para cada entrada da tabela de fluxos e podem ser controlados
e acessados pelo controlador por meio do protocolo OpenFlow.
Aps definida a entrada a tabela de fluxo, cada pacote que chega a um comutador
OpenFlow comparado com cada entrada nessa tabela e caso um casamento seja
encontrado, considera-se que o pacote pertence quele fluxo e por sua vez ir agir
de acordo com uma ao preestabelecida, exemplo: aes do tipo (a) ou (d). Caso o
casamento no seja encontrado, o pacote encaminhado por completo para o controlador para ser processado, ao do tipo (b), ou pode ser apagado de acordo com
alguma poltica de segurana preestabelecida, ao do tipo (c). Alternativamente,
apenas o cabealho encaminhado ao controlador mantendo o pacote armazenado
no buer do hardware. Caso o pacote seja encaminhado ao controlador, o controlador analisar o pacote e dependendo da anlise da aplicao poder criar uma nova
entrada para aquele fluxo.
Em geral, os pacotes que chegam ao controlador sempre correspondem ao primeiro pacote de um novo fluxo ou, dependendo da aplicao, o controlador pode optar por instalar uma regra no comutador para que todos os pacotes de determinado
fluxo sejam enviados para o controlador para serem tratados de maneira individual.
Esse ltimo caso corresponde normalmente a pacotes de controle(ICMP, DNS, DHCP)
ou protocolos de roteamento (OSPF, BGP) [40].
Essas tabelas de fluxo criam um conjunto de regras que podem servir em diversas
possibilidades, muitas das funcionalidades que so implementadas separadamente
podem ser agrupadas em um nico controlador OpenFlow, como por exemplo, funcionalidades que implementam servios como NAT, firewall e VLANs. Alguns exemplos
de possibilidades so apresentadas na Figura 4.3, em que cada linha representa um
fluxo com suas respectivas aes a serem tomadas.
46
Figura 4.3: Exemplo de uma tabela de fluxos de um comutador OpenFlow. O campo

representado por um * indica que qualquer valor aceito naquela posio, ou seja
um campo que no importa no reconhecimento do fluxo [19].
Apesar do protocolo OpenFlow possuir um pequeno conjunto de aes simples
ele ainda capaz de prover uma vasta gama de possibilidades para o desenvolvimento de aplicaes de rede, isso se deve ao fato que esses conjuntos de aes se
bem combinados e desenvolvidos em uma aplicao podem atender aos requisitos
especficos de um determinado fluxo. Somando-se isso ao fato de uma rede OpenFlow executar mltiplas aplicaes em paralelo atendendo os requisitos especficos
de diversos fluxos com um controle lgico central o OpenFlow torna-se uma tima
alternativa para a nova arquitetura da Internet do Futuro.
4.6
Aplicaes do OpenFlow
O OpenFlow permite o experimento de novas propostas na rea de redes de computadores podendo at mesmo utilizar uma infraestrutura de rede j existente. Dentre as possveis aplicaes que se pode realizar com uma rede OpenFlow, podem ser
classificadas as seguintes: [19]
Novos protocolos de roteamento - Como vimos, aplicaes diversas podem tratar de fluxos especficos de uma rede OpenFlow. Assim quando um pacote de
um novo fluxo chegar a um comutador, ele encaminhado para o controlador
que responsvel por escolher a melhor rota para o pacote seguir na rede a partir de uma poltica adotada pela aplicao (um novo protocolo de roteamento)
correspondente. Aps isso, o controlador adiciona as entradas na tabela de
fluxos de cada comutador pertencente a rota escolhida e os prximos pacotes
desse fluxo que forem encaminhados na rede no necessitaro ser enviados
para o controlador. Dessa forma novos protocolos de roteamento podem ser
implementados para diversos fluxos especficos na rede de forma que tais protocolos cuidem separadamente de um conjunto de fluxos.
Mobilidade - Uma rede OpenFlow que possui pontos de acesso sem fio permite
que clientes mveis utilizem sua infraestrutura para se conectarem a Internet.
47
Dessa forma mecanismos de hando 2 podem ser executados no controlador

com uma simples migrao dinmica das tabelas de fluxo dos comutadores
de acordo com a movimentao do cliente, permitindo a redefinio da rota
utilizada.
Redes no IP - O comutador OpenFlow analisa arbitrariamente os campos do pacote para definir a qual fluxo ele pertence de acordo com a tabela de fluxos
do comutador, permitindo a flexibilidade na definio do fluxo. Dessa forma
podem ser testadas, por exemplo, novas formadas de endereamento e encaminhamento para as redes de computadores sob a arquitetura OpenFlow.
Redes com processamento de pacotes - Existem aplicaes OpenFlow que realizam processamento de cada pacote de um fluxo, nesse caso a aplicao
implementada no controlador OpenFlow cria uma regra nos comutadores da
rede forando que cada pacote recebido seja enviado ao controlador para ser
analisado e processado pela aplicao. Como j mencionado esses casos correspondem, em geral, a pacotes de controle (ICMP, DNS, DHCP) ou protocolos
de roteamento (OSPF, BGP).
4.7
O OpenFlow Atualmente
O OpenFlow pode ser visto como uma tecnologia promissora e inovadora que abre
uma srie de oportunidades de desenvolvimento tecnolgico na reas das redes de
computadores. Esse fator potencial da tecnologia OpenFlow tm atrado a ateno
da indstria no desenvolvimento de prottipos com suporte ao OpenFlow (HP, NEC,
Extreme, Arista, Ciena, Juniper, Cisco); no suporte dos fornecedores de processadores em silcio (Broadcom, Marven); na criao de empresas como a Nicira e a Big
Switch Networks; e no interesse de operadoras e provedores de servio, tais como
Deutsche Telekom, Docomo, Google, Facebook e Amazon. Espera-se que medida
que a especificao OpenFlow evolua, mais fabricantes de equipamentos incorporem
o padro em suas solues comerciais.
O projeto, inicialmente desenvolvido na Universidade de Stanford, continua sendo
desenvolvido pela Open Networking Foundation (ONF). A verso 1.1 do protocolo
OpenFlow foi lanada em 28 de fevereiro de 2011 possuindo ainda algumas limitaes em termos do uso do padro em circuitos pticos e uma definio de fluxos
que englobe protocolos que no fazem parte do modelo TCP/IP. Em fevereiro de 2012
a ONF publicou a verso 1.2 do OpenFlow, melhor especificado mais flexvel e com
menos restries.
Em maio de 2012 a Indiana University em parceria com a ONF lanou o SDN Interoperability Lab que incentiva o desenvolvimento e a adoo de normas paras as redes
SDN com a tecnologia OpenFlow. Em fevereiro de 2012 a Big Switch Networks lanou o controlador Floodlight j mencionado anteriormente. Nesta mesma data a HP
2
Hando o procedimento empregado em redes sem fio para tratar de uma unidade mvel de
uma clula para outra de forma transparente ao utilizador.
48
anunciou que estava tomando providncias para lanar o seus primeiro equipamentos de rede com OpenFlow habilitado. E em abril de 2012 a Google descreveu como
uma rede interna da empresa tinha sido reprojetada para uma arquitetura OpenFlow
com melhoria de desempenho e eficincia relevantes.
Tudo isso demonstra que a consolidao das tecnologias de equipamentos programveis em software no padro OpenFlow, ampliou o conceito de redes definidas
por software envolvendo-o a novos paradigmas de gerncia integrada, inovao em
protocolos e servios baseados em recursos de redes virtualizadas ou definidas por
software.
49
Captulo 5
Controlador POX
O principal componente de uma Rede Definida por Software, como j apresentado, o controlador SDN, tambm chamado de sistema operacional de rede. O
controlador o que define a natureza do paradigma SDN. o componente responsvel por concentrar a comunicao com todos os elementos programveis da rede,
oferecendo uma viso unificada da rede.
Como vimos, existem diversos controladores para o paradigma SDN. A maneira
de como desenvolver aplicaes SDN depende muito da linguagem de programao
em que o controlador foi desenvolvido bem como sua arquitetura e complexidade.
Entre todos os controladores destacados apresentado o POX, um controlador SDN
desenvolvido especificamente para fins de pesquisa e ensino.
Este captulo apresenta as principais caractersticas do POX, os detalhes da sua arquitetura e os elementos principais para a programao de componentes do mesmo
de acordo com as especificaes encontradas em POX Wiki [1].
5.1
Capacidades do POX
O POX vm sendo desenvolvido com o objetivo de substituir o NOX em iniciativas

de pesquisa e ensino. Ele considerado o irmo mais novo do NOX, sua essncia
uma plataforma simples para o desenvolvimento e prototipagem rpida de software
de controle de rede usando o Python.
O objetivo dos desenvolvedores que ele a venha substituir o NOX nos casos em
que o desempenho no seja um requisito crtico. Como pode-se ver na Figura 5.1,
observamos que o desempenho do NOX sendo executado em C++ superior ao
POX, porm nos casos em que o NOX executado em Python o POX mais eficiente
oferecendo um melhor desempenho. Alm disso o POX traz consigo uma interface
mais moderna e uma pilha SDN mais elegante. Por esses motivos que o POX
considerado para fins de pesquisa e ensino no desenvolvimento de aplicaes SDN.
50
(a) Teste de latncia(ms/fluxo)
(b) Teste de vazo(fluxo/seg)
Figura 5.1: Comparaes de desempenho entre o POX e o NOX [34].
5.2
Instalao do POX
Para se executar o POX necessrio ter o Python 2.7 ou superior instalado no seu
sistema operacional. O POX suportado pelos sistemas Windows, Linux e Mac OS,
sendo este ltimo o mais recomendado.
O POX distribudo e hospedado no github1 em http://github.com/noxrepo/pox.
5.3
Executando o POX
Para se iniciar o POX necessrio executar o mdulo pox.py, para isso fazemos:
./pox.py em um terminal. O POX tem algumas opes de inicializao que podem
ser usadas na linha de comando, so elas:
Quadro 5.1: Opes de inicializao do POX.
Opo
verbose
nocli
noopenflow
Descrio
Para exibir informaes extras, muito til para a depurao de problemas de inicializao.
Serve para que no inicialize a interface interativa de
comandos (no muito til).
No inicializar o mdulo openflow automaticamente.
Executar o POX sem nenhum mdulo no faz muito sentido. O POX funciona a
partir de mdulos e componentes, no qual o pblico-alvo so os pesquisadores que
queiram desenvolver seus prprios componentes. Dessa forma os pesquisadores
tem apenas o trabalho de desenvolver seus componentes e execut-los no POX.
Para executar os componentes basta especific-los na linha de comando aps
qualquer uma das opes acima ou apenas aps a chamada do mdulo pox.py dessa
forma:
1
Site de colaborao, anlise e gerenciamento de cdigos abertos para projetos em desenvolvimento https://github.com/
51
./pox.py nocli [meu mdulo]
possvel especificar vrios componentes na linha de comando. Em geral alguns

componentes no funcionam bem em conjunto e alguns componentes dependem de
outros componentes, isso depender muito do ambiente de trabalho do pesquisador.
Dessa forma possvel especificar vrios componentes da seguinte maneira:
./pox.py nocli [mdulo1] [meu mdulo2]
Os componentes podem ter argumentos prprios, para execut-los com essas opes basta colocar o nome do componente seguido da opo com dois traos, dessa
forma:
./pox.py nocli [mdulo1] [opo] [meu mdulo2] [opo]
No caso em que o pesquisador precise iniciar muitos mdulos com muitas opes a linha de comando pode ficar um pouco confusa, para isso basta escrever um
componente simples que lana outros componentes.
5.4
Componentes do POX
Os componentes do POX so programas que so executados no controlador, em

outras palavras os componentes fornecem as funes para que o controlador trabalhe em uma rede SDN de acordo com a poltica do(s) componente(s). Dessa forma
quando se fala em componentes para o POX quer-se dizer o que possvel colocar
na linha de comando do POX em sua inicializao.
O POX j traz consigo alguns componentes bsicos entre eles h alguns convenientes para testes e h outros que so apenas exemplos, mas a inteno que o
pesquisador possa criar seu prprio componente. Nos Quadros A.1, A.2 e A.3 (Apndice A) so apresentados alguns destes componentes, alguns esto somente na verso beta.
Dentre os apresentados podemos destacar o componente py, que inicializa um
interpretador Python para depurao interativa, o componente forwarding.l2_learning, que faz com que os switches OpenFlow funcionem como switches de auto
aprendizagem e o componente misc.of_tutorial, que trata-se do tutorial OpenFlow2 para iniciantes.
2
OpenFlow Tutorial http://www.openflow.org/wk/index.php/OpenFlow_Tutorial
52
5.5
Compreendendo a Funo launch()
Em geral todos os componentes devem ter uma funo chamada launch. Quando
executamos o POX e chamamos algum componente, o POX executa a funo launch()
deste componente. Esta funo deve realizar todas as aes do componente instanciando classes ou chamando outras funes e mtodos. Por exemplo:
1
2
3
4
5
def launch ( ) :
p r i n t "Meu componente "
" " "
Outras operacoes a serem executadas
" " "
Caso a funo launch receba parmetros, possvel atribu-los na linha de comando quando inicializar o POX.
1
2
3
4
5
def launch ( a , b = " d o i s " , c = True ) :

p r i n t "Meu componente imprime : " , a , b , c
" " "
Outras operacoes a serem executadas
" " "
Podemos inicializar os parmetros dessa forma no terminal:
./pox.py meu_coponente a=3 b c=disabled
Note que neste exemplo o parmetro a no recebe nenhum valor padro. Caso
tente iniciar o componente sem atribuir um valor nas opes, o POX retornar um
erro. possvel atribuir, nas opes, qualquer tipo varivel, neste caso foi atribudo
um inteiro, mas poderia ser uma string.
Note que ao parmetro a, no foi atribudo nenhum valor, neste caso o Python
atribuiu o valor de a igual a True, caso b no estivesse nas opes de inicializao ele teria atribudo o valor dois.
J o parmetro c, que recebe por padro o valor True, caso se queira enviar
o valor False no ser possvel atribuir diretamente pelas opes de inicializao,
pois o Python entender o valor como uma String. O que se pode fazer criar algum cdigo que converta o valor para False (booleano), ou utilizar-se da funo
pox.lib.util0 s str_to_bool() que aceita valores como on, true ou enabled
como True (booleano) e o restante como False (booleano).
53
5.6
Ncleo do POX
O POX tem um objeto chamado pox.core que serve como repositrio para grande
parte de suas APIs. Sua finalidade principal proporcionar um ponto de encontro
entre os componentes. Para isso os componentes precisam registrar objetos arbitrrios que iro passar a ser acessveis por todos os mdulos do sistema. Por exemplo,
possvel criar um componente e registrar suas funcionalidades no ncleo para que
outros componentes utilizem essas funes sem depender do comando import do
Python, reduzindo o cdigo de inicializao.
Uma das principais vantagens dessa abordagem que as dependncias entre os
componentes no so codificadas, diferentes componentes que exponham a mesma
interface podem troc-las facilmente entre si. Muitos mdulos no POX iro querer ter
acesso ao ncleo, para isso basta importar o objeto:
1
from pox . core import core
Para registrar um objeto no ncleo podemos utilizar o core.register() que leva

dois argumentos, o primeiro o nome que se deseja usar quando for requisitado objetos desse componente, o segundo o objeto que queremos registrar no ncleo.
Segue o exemplo de um componente simples com uma funo launch() que registra o componente coisa.
1
2
3
4
5

c l a s s MeuComponente ( o b j e c t ) :
def _ _ i n i t _ _ ( s e l f , an_arg ) :
s e l f . arg = an_arg # A t r i b u i c a o da i s t a n c i a a v a r i a v e l arg
p r i n t " \ n \ nMeuComponente TEM que imprime a v a r i a v e l arg : " , s e l f . arg
6
7
8
def funcao ( s e l f ) :
p r i n t " \ n \ nMeuComponente ESTA imprimindo a v a r i a v e l arg : " , s e l f . arg , " \
n \ n"
9
10
11
12
13
def launch ( ) :
componente = MeuComponente ( "spam" )
core . r e g i s t e r ( " c o i s a " , componente )
core . c o i s a . funcao ( ) # i r a i m p r i m i r : " MeuComponente esta imprimindo a
v a r i a v e l arg : spam"
Existem outras formas de se registrar objetos no ncleo, para maiores informaes consulte a POX Wiki [1].
5.7
Eventos no POX
O POX orientado a eventos, seu sistema de controle implementado pela biblioteca pox.lib.revent. O princpio desta implementao que os objetos se tornam
54
eventos e no apenas uma coleo de campos e mtodos. Um objeto pode disparar eventos e outros podem esperar por esses eventos registrando manipuladores
(handlers).
Eventos no POX so todos os objetos instanciados de subclasses de revent.Event.
Um objeto que gera eventos deve herdar de revent.EventMixin. Tais objetos normalmente especificam quais tipos de eventos ele pode disparar. Dessa forma esses
eventos so normalmente classes que estendem de Event passando a possuir certas caractersticas, mas na prtica podem ser qualquer coisa. O objeto que esteja
interessado em um evento pode registrar um manipulador (handler) para ele.
Alternativamente possvel escutar eventos diretamente, utilizando o ncleo do
POX. A classe que cria os eventos, que herdam de revent.EventMixin, pode registrar
objetos no ncleo do POX de maneira que, para as classe que queiram ouvir esses
eventos, basta executar o mtodo registrado no ncleo do POX. o que acontece com
a classe pox.openflow.of_01 que cria os eventos openflow e registra eles no mtodo
core.openflow.addListeners(self) do ncleo do POX.
Caso um objeto tenha interesse em todos os eventos disparados por outro objeto no necessrio registrar um manipulador para cada evento, pode-se utilizar
o mtodo EventMixin.listenTo(). Por exemplo, se existem duas classes Abc e Def
que herdam de revent.EventMixin e se Abc disparasse os eventos x e y, para que
Def possa registrar manipuladores para esses eventos normalmente seria necessrio definir os seguintes mtodos handle_x e handle_y. Porm a classe Def pode
registrar todos os eventos de Abc de uma s vez simplesmente executando o mtodo EventMixin.listenTo() da seguinte maneira: self.listenTo(someAbcObject).
Essa forma usualmente mais simples que registrar um manipulador para cada
evento. Maiores informaes sobre os eventos do POX podem ser encontrados em
POX Wiki [1]
5.8
Pacotes do POX
Por ser um controlador de redes SDN, o POX tem que interagir com diversos tipos
de pacotes. Para isso o POX tem uma biblioteca exclusiva para a anlise e construo
de pacotes, a biblioteca pox.lib.packet.
Esta biblioteca tem suporte a uma srie de tipos de pacotes, a maioria desses
pacotes tem algum tipo de cabealho e uma espcie de carga til (payload) que
muitas vezes outro tipo de pacote. Por exemplo, o POX frequentemente trabalha
com pacotes ethernet, que por sua vez contm pacotes ipv4 e que por sua vez
contm pacotes tcp. So alguns tipos de pacotes suportados pelo POX:
ethernet
IPv4
TCP
DHCP
LLDP
ARP
ICMP
UDP
DNS
VLAN
55
As classes de pacotes no POX podem ser encontradas no diretrio pox/lib/packet.

Para importar a biblioteca de pacotes basta fazer:
1
import pox . l i b . packet as pkt
Pode-se navegar pelos pacotes encapsulados de duas maneiras, usando o mtodo

payload de cada pacote para obter o pacote superior da pilha de protocolos TCP/IP ou
usando o mtodo find(). Um exemplo simples de como possvel analisar pacotes
ICMP usando o payload.
1
2
def parseICMP ( packet ) :

i f eth_packet . type == e t h e r n e t . IP_TYPE : # v e r i f i c a se o pacote e t h e r n e t
contem um pacote i p
i p _ p a c k e t = eth_packet . payload # i p _ p a c k e t recebe o payload de
eth_packet
i f i p _ p a c k e t . p r o t o c o l = ipv4 . ICMP_PROTOCOL # v e r i f i c a se o pacote
i p u t i l i z a o p r o t o c o l o icmp
icmp_packet = i p _ p a c k e t . payload # icmp_packet recebe o payload
de i p _ p a c k e t
...
Um maneira mais simples de obter os pacotes utilizando o mtodo find(). Ele

localiza o pacote encapsulado pelo nome, por exemplo, ipv4. Caso o mtodo nao
encontre nenhum pacotes deste tipo ele retornar None (nada). Por exemplo:
1
2
3
4
5
6
def h a n d l e _ I P _ p a c k e t ( packet ) :
i p = packet . f i n d ( ipv4 ) # u t i l i z a c a o do metodo f i n d ( )
i f i p i s None :
# Este pacote nao tem pacote i p
return
p r i n t " Fonte do pacote I P : " , i p . s r c i p # imprime a f o n t e do pacote i p
Os Quadros A.4, A.5 e A.6 (Apndice A) mostram uma anlise de algumas das principais classes da biblioteca pox.lib.packet, maiores detalhes sobre as outras classes
podem ser encontradas em suas classes especificas no diretrio pox/lib/packet.
5.9
Threads no POX
Geralmente o modelo de eventos no levanta a necessidade do uso de threads,

porm caso algum componente queira executar alguma ao ao longo do tempo,
56
como por exemplo, examinar os bytes transferidos ao longo de um fluxo especfico a

cada dez segundos, interessante entender o modelo de threads utilizado no POX.
O modelo de threads do POX modelado pela biblioteca pox.lib.recoco. Esta
biblioteca cria um modelo de threads cooperativas em que as prprias threads delegam o processamento entre si. Diferente do que ocorre no modelo preemptivo no
qual o sistema ativamente interrompe o processamento de um thread e o delega a
outra.
Dessa forma todas as threads cooperativas precisam ser criadas por uma classe
que estenda pox.lib.recoco.Task e implemente o mtodo run. Aps a sua criao
a thread precisa ser escalonada e quando for escolhida para ser executada ela pode
se considerar um processo atmico, que ir ser executada at o final ou at bloquear
a si prpria com o mtodo Sleep().
Ao trabalhar com threads deve-se ter cautela para evitar executar uma operao
que pode bloquear o funcionamento do sistema. Por esses motivos interessante
trabalhar com a classe pox.lib.recoco.Timer que por sua vez j estende da classe
Task facilitando muito o trabalho do modelo de threads.
A classe Timer foi projetada para lidar com a execuo de pedaos de cdigos
de uma nica vez ou de forma recorrente. Esta classe j lida com modelo de threads automaticamente, bastando apenas definir seus argumentos de entrada quando
chamada. No apndice A podem ser encontrados os Quadros A.7 e A.8, que mostram
os argumentos de construo da classe, e o Quadro A.9, que mostra seus mtodos.
Outra maneira possivel de se trabalhar com thread utilizar-se do ncleo do POX
com o objeto callDelayed() que age exatamente da mesma maneira do Timer sem
que se precise importar a biblioteca recoco.
Exemplo de como se trabalhar com threads (Disparo de uma nica vez):
1
from pox . l i b . recoco import Timer
2
3
4
def h a n d l e _ t i m e r _ e l a p s e ( mensagem ) :
p r i n t "Me mandaram f a l a r : " , mensagem
5
6
Timer ( 1 0 , han dle_ti mer_e lapse , args = [ " Ola " ] )
7
8
# I r a i m p r i m i r "Me mandaram f a l a r : Ola " em 10 segundos
9
10
11
12
# Uma o u t r a maneira de se f a z e r o Timer u t i l i z a n d o o nucleo do POX :

from pox . core import core # Muitos componente fazem i s s o !
core . c a l l D e l a y e d ( 1 0 , h a n d l e r _ t i m e r _ e l a p s e , " Ola " )
Exemplo de como se trabalhar com threads (Disparo recorrente):

1
# Simula uma longa viagem
2
3
from pox . l i b . recoco import Timer
4
5
nos_estamos_la = F a l s e
57
7
8
9
10
def n o s _ j a _ e s t a m o s _ l a ( ) :
i f nos_estamos_la :
r e t u r n F a l s e # Cancela o Timer ( v e j a o s e l f S t o p p a b l e )
p r i n t " Nos j a estamos l a ? "
11
12
Timer ( 3 0 , nos_ja_estamos_la , r e c u r r i n g = True ) # f i c a r a imprimindo a

pergunta : " Nos j a estamos l a ? " a cada 30 segundos ate nos_estamos_la =
True , e cancela o Timer .
5.10
OpenFlow no POX
O propsito principal do POX desenvolver aplicaes de controle OpenFlow. Esta

seo descreve algumas caractersticas das interfaces de controle OpenFlow do POX.
A biblioteca OpenFlow implementa facilidades para a comunicao com comutadores
OpenFlow e para a recepo e criao de pacotes.
O POX tem um componente que se comunica diretamente com os comutadores
OpenFlow, este componente o openflow.of_01 (01 refere-se a verso do protocolo OpenFlow 1.0). Como j foi dito este componente inicia automaticamente ao se
executar o POX (a menos que a opo noopenflow seja declarada) e quando
iniciado, por padro, ele registra um objeto no ncleo do POX (pox.core) com o nome
openflow. Essa a principal interface para se trabalhar com o OpenFlow no POX.
possvel utilizar este objeto para enviar e receber mensagens de controle para os
comutadores com OpenFlow habilitado.
O POX trabalha com o OpenFlow por meio de eventos. Os eventos so registrados
pelo componente of_01 e podem ser observados por qualquer outro componente ao
registrar um tratador (handle) para esses eventos. Por exemplo, pacotes oriundos
de comutadores OpenFlow so recebidos pelo objeto openflow, que por sua vez gera
um evento PacketIn que pode ser observado por qualquer outro componente que
esteja interessado na chegada do pacote.
A maioria dos eventos relacionados ao OpenFlow so criados em resposta direta a
uma mensagem recebida pelo comutador OpenFlow. Em geral os eventos OpenFlow
tm os seguintes atributos (Quadro 5.2):
Quadro 5.2: Atributos gerais dos Eventos OpenFlow no POX.
Atributo
connection
dpid
ofp
Tipo
Connection
Descrio
a conexo com o comutador que causou
esse evento
long
Corresponde ao ID do comutador que causou
o evento
ofp_header subclass a mensagem OpenFlow que o evento trs,
a seo 5.11 explica os tipos de mensagens
58
O mdulo OpenFlow fornece vrios eventos para controle de mensagens OpenFlow, esses eventos so descritos nos Quadros A.10 e A.11 (Apndice A). Todos os
eventos so registrados pelo mdulo OpenFlow do POX e suas classes podem ser
encontradas em pox.openflow.__init__.py, maiores detalhes de seus atributos e
mtodos podem ser encontrados em POX Wiki [1].
A seguir apresentado um componente que escuta os eventos ConnectionUp,
ConnectionDown, PortStatus, PacketIn e FlowRemoved respectivamente.
1
2

from pox . l i b . u t i l import d p i d T o S t r # d p i d T o S t r e um metodo que converte o
i d de um comutador para s t r i n g
3
4
l o g = core . getLogger ( ) # para e x i b i r l o g s no sistema , neste exemplo e

u t i l i z a d o o l o g . debug ( )
5
6
7
8
c l a s s MyComponent ( o b j e c t ) :
def _ _ i n i t _ _ ( s e l f ) :
core . openflow . a d d L i s t e n e r s ( s e l f ) # para o u v i r todos os eventos OpenFlow
do core
9
10
11
def _handle_ConnectionUp ( s e l f , event ) : # t r a t a d o r de eventos

ConnectionUp , todas as vezes que este evento o c o r r e r , este metodo e
executado
l o g . debug ( "O s w i t c h %s se conectou ao c o n t r o l a d o r . " , d p i d T o S t r ( event .
dpid ) )
12
13
14
def _handle_ConnectionDown ( s e l f , event ) : # t r a t a d o r de eventos

ConnectionDown
l o g . debug ( "O s w i t c h %s perdeu a conexao com o c o n t r o l a d o r . " , d p i d T o S t r (
event . dpid ) )
15
16
17
18
19
20
21
22
23
def _ h a n d l e _ P o r t S t a t u s ( s e l f , event ) : # t r a t a d o r de eventos P o r t S t a t u s

i f event . added :
a c t i o n = " adicionada "
e l i f event . de lete d :
action = " retirada "
else :
a c t i o n = " modificada "
l o g . debug ( "A p o r t a %s no s w i t c h %s f o i %s . " , ( event . port , d p i d T o S t r (
event . dpid ) , a c t i o n )
24
25
26
27
def _ h a n d l e _ P a c k e t I n ( s e l f , event ) : # t r a t a d o r de eventos P a c k e t I n

l o g . debug ( " Chegou um pacote no s w i t c h %s " pela p o r t a %d , d p i d T o S t r (
event . connection . dpid ) , event . p o r t )
packet = event . parsed # para que se possa t r a b a l h a r com o pacote
28
29
30
def _handle_FlowRemoved ( s e l f , event ) : # t r a t a d o r de eventos FlowRemoved

l o g . debug ( " Fluxo f o i removido no s w i t c h %s " , d p i d T o S t r ( event . dpid ) )
31
32
33
def launch ( ) :
core . registerNew ( MyComponent ) # r e g i s t r a n d o o componente no nucleo ( core )
59
Para que se possa compreender melhor o que esse componente faz, basta executlo juntamente com um componente do tipo forwarding como o forwarding.l2_learning e observar sua sada.
5.11
Mensagens OpenFlow no POX
So com as mensagens OpenFlow que os comutadores se comunicam com os controladores. Todas essas mensagens so definidas na Especificao OpenFlow [42].
Existem vrias verses da especificao, o POX atualmente trabalha com o OpenFlow
verso 1.0.
O POX contm classes e constantes que correspondem a todos os elementos
do protocolo OpenFlow, eles esto definidos em pox.openflow.libopenflow_01.py.
Grande parte dos nomes das classes so os mesmos da especificao, outros no
entanto se diferem para se adequar ao sistema, alm disso o POX define algumas
estruturas que no correspondem a nenhuma estrutura da especificao. Adiante
apresentado algumas dessas classes e suas descries bsicas.
5.11.1
of.ofp_packet_out
O principal objetivo desta mensagem instruir um comutador a enviar um pacote

em uma determinada porta. Outra utilidade desta mensagem instruir um comutador a descartar um pacote que esteja no seu buer. Esta classe pode ser encontrada
na linha 2886 do arquivo pox/openflow/libopenflow_01.py. Os Quadros A.12 e A.13
(Apndice A) mostram os atributos e as descries da classe.
5.11.2
of.ofp_flow_mod
O principal objetivo desta mensagem modificar as tabelas de fluxo de um comutador. O controlador pode adicionar, modificar e deletar entradas na tabela de
fluxo de um comutador. Esta classe pode ser encontrada na linha 1816 do arquivo
pox/openflow/libopenflow_01.py. Exemplos de como realizar uma entrada na tabela de fluxo de um comutador podem ser vistos em POX Wiki [1]. Os Quadros A.14
e A.15 (Apndice A) mostram os atributos e as descries da classe.
5.11.3
of.ofp_match
Esta classe define a estrutura de um fluxo. possvel construir estruturas de

fluxo a partir do nada para que possam ser utilizadas em outras classes OpenFlow
do POX. Esta classe pode ser encontrada na linha 405 do arquivo pox/openflow/
libopenflow_01.py. O Quadro A.16 (Apndice A) mostra os atributos e suas descries. Exemplo de como criar uma estrutura de um fluxo:
1
2
# c r i a r uma e s t r u t u r a de f l u x o em uma l i n h a
my_match = o f . ofp_match ( i n _ p o r t = 5 , d l _ d s t = EthAddr ( " 0 1 : 0 2 : 0 3 : 0 4 : 0 5 : 0 6 " ) )
60
4
5
6
7
#ou c r i a r uma e s t r u t u r a de f l u x o em v a r i a s l i n h a s
my_match = o f . ofp_match ( )
my_match . i n _ p o r t = 5
my_match . d l _ d s t = EthAddr ( " 0 1 : 0 2 : 0 3 : 0 4 : 0 5 : 0 6 " )
5.11.4
ofp_action
um conjunto de classes que definem aes possveis de uma regra. Quando

definida uma ao (uma classe) o comutador realizar esta ao a partir do fluxo
registrado na tabela de fluxos. Essas classes podem ser encontradas no arquivo
pox/openflow/ libopenflow_01.py. O Quadro A.17 (Apndice A) mostra as classes
de ao do POX e suas descries. Maiores detalhes sobre o funcionamentos dessas
classe podem ser encontrados em POX Wiki [1].
5.12
Desenvolvendo Componentes Prprios
Esta seo mostra como construir um componente prprio para o POX. Em alguns
casos o pesquisador pode reutilizar trechos de cdigos de alguns componentes j
existentes nos seus prprios componentes. Nesses casos possvel fazer uma copia
de algum componente e trabalhar em cima deles. O Capitulo 7 mostrar como criar
componentes mais concretos e como test-los.
Como podemos observar os componentes do POX so apenas mdulos Python.
possvel colocar esses mdulos em qualquer lugar. O usual colocar esse mdulos
no diretrio ext. Este diretrio o local mais conveniente para que os pesquisadores
possam colocar seus componentes prprios, pois o POX pesquisa automaticamente
esse caminho quando executado.
Dessa forma uma maneira simples de comear a construir um componente prprio copiar um componente j existente (forwarding.l2_learning.py) para o diretrio ext, renome-lo (meu_componente.py) e comear a modificar o arquivo. Para
executar ele no POX basta dar o comando: ./pox.py meu_coponente.
5.12.1
Como criar um componente bsico no POX
Esta seo mostra como criar um componente para o POX. Primeiramente necessrio criar um arquivo em branco no diretrio ext (de preferncia). Por exemplo
o arquivo teste.py. Abra o arquivo (vide cdigo a seguir) e crie o mtodo launch()
(linha 22) e se quiser alguns parmetros (Seo 5.5). Este mtodo executado assim
que o POX chama o componente. interessante registrar o componente no ncleo
do POX, seo 5.6 (linha 23 ou 25). Agora necessrio criar a classe do componente teste (linha 6), essa classe deve escutar os eventos openflow, para isso
necessrio executar o mtodo addListeners do ncleo do POX (Seo 5.7) (linha
9). Agora que o componente teste pode escutar eventos necessrio criar funes
para tratar certos eventos. Para tratar o evento ConnectionUp, que lanado toda
61
vez que o POX detecta uma nova conexo, necessrio criar um tratador para ele,
o mtodo _handle_ConnectionUp (linha 14), esse mtodo recebe como parmetro o
prprio evento e pode realizar qualquer tarefa com ele (Seo 5.10). O componente
teste.py ficar assim:
1
2

from pox . l i b . u t i l import d p i d T o S t r # d p i d _ t o _ s t r e um metodo que converte o
i d de um comutador para s t r i n g
3
4
l o g = core . getLogger ( ) # para e x i b i r l o g s no sistema , neste exemplo e

u t i l i z a d o o l o g . debug ( )
5
6
7
8
9
c l a s s Teste ( o b j e c t ) :
def _ _ i n i t _ _ ( s e l f , an_arg ) :
s e l f . arg = an_arg
core . openflow . a d d L i s t e n e r s ( s e l f ) # para o u v i r todos os eventos OpenFlow
do core
10
11
12
def meu_nome ( s e l f ) :
p r i n t " Sou o componente : " , s e l f . arg
13
14
15
16
def _handle_ConnectionUp ( s e l f , event ) : # t r a t a d o r de eventos

ConnectionUp , todas as vezes que este evento o c o r r e r , este metodo e
executado
l o g . debug ( "O s w i t c h %s se conectou ao c o n t r o l a d o r . " , d p i d T o S t r ( event .
dpid ) )
s e l f . meu_nome ( )
17
18
19
20
def _ h a n d l e _ P a c k e t I n ( s e l f , event ) :
# executando o metodo r e g i s t a r d o no nucleo do pox
core . t e s t e . meu_nome ( ) # i m p r i m i r a " Sou o componente : TesteOpenFlow " toda
vez que um pacote chegar
21
22
23
24
25
def launch ( ) :
component = Teste ( " TesteOpenFlow " )
core . r e g i s t e r ( " t e s t e " , component ) # r e g i s t r a n d o o componente t e s t e
# o u t r a maneira de r e g i s t r a r o componente : core . registerNew ( Teste )
Para execut-lo faa:
./pox.py teste.py
necessrio deixar claro que o cdigo gerado aqui funcionar tanto em redes
SDN reais como no simulador MiniNet, que ser explicado no prximo captulo. No
Captulo 7 ser mostrado como testar os componentes aqui apresentados e como
criar componentes mais realistas e mais complexos.
62
Captulo 6
MiniNet
Para a criao de uma arquitetura SDN necessrio mltiplos componentes em
sua infraestrutura. Inicialmente precisamos de uma mquina controladora operando
algum sistema operacional de rede, como por exemplo, o NOX ou o POX. Posteriormente se fazem necessrios elementos encaminhadores que tenham o plano de
controle separado do plano de dados com alguma interface de programao, como
por exemplo o OpenFlow. Alm disso, ainda necessrio toda uma infraestrutura
fsica que interligue esses elementos encaminhadores e o controlador por um canal
seguro para a criao de uma Rede Definida por Software.
Ocorre que nem sempre um pesquisador dispe de uma infraestrutura como essa
para realizar seus experimentos, pois essa estrutura possui um custo elevado. Para
lidar com esse problema possvel usar um simulador de Redes Definidas por Software.
O MiniNet uma ferramenta para a simulao de Redes Definidas por Software
que permite a rpida prototipao de uma grande infraestrutura virtual de rede com
a utilizao de apenas um computador. O Mininet tambm possibilita a criao de
prottipos de redes virtuais escalveis baseados em software como OpenFlow utilizando primitivas de virtualizao do Sistema Operacional. Com essas primitivas, ele
permite criar, interagir e customizar prottipos de Redes Definidas por Software de
forma rpida.
So algumas caractersticas do MiniNet:
Fornecer uma maneira simples e barata para a realizao de testes em redes
para desenvolvimento de aplicaes OpenFlow;
Permite que mltiplos pesquisadores possam trabalhar de forma independente
na mesma topologia de rede;
Permite o teste de uma topologia grande e complexa, sem mesmo a necessidade de uma rede fsica;
Inclui ferramentas para depurar e executar testes em toda a rede;
D suporte a inmeras topologias, e inclui um conjunto bsicos de topologias;
Oferece APIs simples em Python para criao e experimentao de redes.
63
Com o MiniNet possvel realizar testes de depurao e de resolues de problemas podendo se beneficiar de ter uma rede completa experimental em um laptop
ou PC. Fornece, de maneira intuitiva, ferramentas para o desenvolvimento de aprendizagem na rea de redes. Sua interface permite sua utilizao em pesquisas e em
aulas para o uso prtico de tcnicas e solues de redes.
O MiniNet melhor executado em mquina virtual (VM MiniNet) sendo executada em VMware ou VirtualBox para os sistemas operacionais Windows, Mac e Linux
com ferramentas OpenFlow j instaladas. Alternativamente possvel instala-lo no
Ubuntu 11.10, embora os desenvolvedores no recomendem.
Mesmo com todas essas qualidades o MiniNet ainda no fornece desempenho e
qualidade fieis de uma rede real, embora o cdigo utilizado nele sirva para uma
rede real baseada em switches de software NetFPGAs1 , ou switches e, hardware
comerciais. Isso ocorre devido aos recursos que so multiplexados em tempo real
pelo kernel da mquina simuladora, e uma vez que a largura de banda total limitada
por restries de CPU e memria da mesma.
Este captulo ir apresentar um passo-a-passo dos principais comandos do MiniNet, assumindo uma utilizao com mquinas virtuais. Mostrar tambm o passo-apasso de como estabelecer um ambiente virtual de testes para a criao e o desenvolvimento de uma arquitetura baseada em Redes Definidas por Software. Com as
explicaes deste captulo possvel compreender melhor o MiniNet e, assim, poder
executar os componentes do POX em uma rede virtual, como ser apresentado no
Captulo 7.
6.1
Funcionamento
Quase todos os sistemas operacionais virtualizam os recursos de computao

usando uma abstrao de processos. O MiniNet usa processos baseados na virtualizao de vrios hosts e switches executados em um nico kernel do sistema operacional.
O MiniNet pode criar switches OpenFlow, controladores e hosts para a comunicao da rede simulada. O MiniNet conecta switches e hosts usando enlaces ethernet
virtuais entre os pares.
O MiniNet ainda depende do kernel do Linux para sua execuo, no entanto seus
desenvolvedores esto desenvolvendo outras tcnicas para sua execuo em outros
sistemas operacionais com virtualizao baseada em processos, como por exemplo
o Solaris.
1
O projeto NetFPGA refere-se ao esforo para o desenvolvimento de hardwares de cdigo aberto

e plataforma de software para permitir a prototipagem rpida de dispositivos de rede. O projeto
visa principalmente os pesquisadores, usurios da indstria e tambm estudantes em sala de aula.
netfpga.org
64
6.2
MiniNet na Prtica
So apresentados os procedimentos de instalao e configurao do VM MiniNet,

que alm de recomendado pelos desenvolvedores mais simples e pode ser executado em Windows, Mac e Linux por meio de uma VMware, VirtualBox, QEMU ou
KVM.
6.2.1
Pr-Requisitos
necessrio um computador com 2GB de RAM e pelo menos 6GB de espao

livre no disco rgido. Um processador mais rpido pode acelerar o tempo de boot da
mquina virtual, e uma tela maior pode ajudar a gerenciar as mltiplas janelas de
terminal.
6.2.2
Download VM MiniNet
O download do VM Mininet pode ser feito em https://github.com/downloads/

mininet/mininet/mininet-vm-ubuntu11.10-052312.vmware.zip. Nele est includo
uma imagem de disco VMware no formato .vmdk (disco de mquina virtual) no qual
pode ser usado na maioria dos sistemas de virtualizao.
necessrio tambm um terminal capaz de se conectar via SSH2 e um servidor
3
X . Com todos esses requisitos devidamente instalados basta inicializar a mquina
virtual com o software de virtualizao de preferncia e extrair o arquivo baixado.
6.2.3
Configurao da VM MiniNet
Antes de executar o VM MiniNet algumas configuraes so necessrias em seu

software de virtualizao:
A escolha do sistema operacional deve ser o Linux Ubuntu;
A alocao deve ser de pelo menos 512Mb de memria para a mquina virtual;
Utilizar duas placas de rede na mquina virtual, sendo uma destinada a sua
prpria rede interna (NAT) e outra para uma interface entre a mquina virtual
e mquina fsica para o uso do SSH (host-only network)
Para realizar essas configuraes consulte a ajuda do software de virtualizao
utilizado. Neste ponto o sistema est pronto para a execuo do VM MiniNet.
Quando estiver executando a mquina virtual use os seguinte parmetros:
2
SSH (Secure Shell) , ao mesmo tempo, um programa de computador e um protocolo de rede

que permitem a conexo com outro computador na rede de forma a permitir execuo de comandos
de uma unidade remota.
3
X Window System, X-Window, X11 ou simplesmente X um software de sistema e um protocolo que fornece uma base para interfaces grficas de usurio (com o conceito de janelas) e funcionalidade rica de dispositivos de entrada para redes de computadores.
65
Username: openflow
Password: openflow
A conta root no est ativada para login, possvel utilizar o comando sudo para
realizar comandos como superusurio.
Primeiro encontre os endereos IPs da mquina virtual, no console escreva:
$ ifconfig
Ser possvel ver trs interfaces (Ex.: eth0, eth1, lo). As duas primeiras so as
configuraes das duas placas de rede j configuradas antes de executar a mquina
virtual. Caso seja possvel ver, basta executar o comando:
$ sudo dhclient eth0

$ sudo dhclient eth1
Execute novamente o comando ifconfig para habilitar as interfaces, que agora

podero ser vistas.
Em alguns casos essas interfaces esto com outros nomes, no entanto o padro
ethX, onde X algum nmero, execute os comandos com esses nomes e verifique
se as interfaces so habilitadas.
Com as interfaces habilitadas anote o endereo IP da segunda interface (host-only
network) que provavelmente seguir o padro de IP da sua mquina fsica. Aps isso
no necessrio utilizar mais o shell da mquina virtual, pois com este IP podemos
conectar a mquina fsica na mquina virtual via SSH, tornando mais fcil a execuo
de comandos e o uso de mltiplas janelas de terminal.
6.2.4
Notas sobre o Prompt de Comando
Os comando apresentados neste documento so mostrados com um prompt de

comando para indicar o subsistema que se destina. Por exemplo:
$ ls
Os comandos seguidos de $ indica que eles devero ser digitados em um prompt

de comando do sistema Unix (Linux ou OS X), seja na mquina virtual ou na prpria
mquina fsica.
66
mininet> h2 ping c3 h3
Os comandos seguidos mininet> indica que eles devero ser digitados no ambiente simulado do MiniNet, somente na mquina virtual, assumindo que se utilizar a
VM MiniNet.
# ping c3 10.0.0.3
Os comandos seguidos # indica que eles devero ser digitados em uma janela de
servidor X. Geralmente so usados quando se acessa algum n na rede virtual. O
smbolo # no Unix tambm indica que voc est com acesso de super usurio.
6.2.5
Acessando a VM MiniNet via SSH
Com todos os requisitos instalados e as configuraes feitas siga:

Para usurios de Mac OS X e Linux: Abra um terminal e digite:
$ ssh X openflow@[Endereo IP anotado(Guest)]
Aps isso ser pedido o password, digite openflow. A opo X para habilitar
o servidor X na mquina virtual. Execute:
$ xterm
Uma nova janela de terminal deve aparecer. Se tiver sucesso ento est feita a
configurao bsica. Feche o xterm. Caso no tenha sucesso verifique a instalao
do servidor X na plataforma. Caso queira outras janelas de SSH repita o processo.
Para usurios de Windows: necessrio executar o servidor X na mquina hospedeira (fsica) e configura-lo para ser executado no SSH instalado. Como servidor X recomendado o Xming4 , como SSH recomendado o PuTTY5 . Para
ativar o Xming no PuTTY abra o PuTTY e v na aba ConnectionSSHX11, e
4
Xming uma implementao do X Windows System para sistemas operacionais do Microsoft

Windows.
5
O PuTTY um cliente SSH destinado a promover o acesso remoto a servidores via Shell Seguro
e a construo de tneis cifrados entre servidores.
67
em seguida marque a caixa Enable X11 Forwarding. Aps essa configurao

v na aba Session e em Host Name (or IP address) na caixa de texto digite o
IP anotado anteriormente da sua mquina virtual. Em Port escreva 22. No
esquea de deixar marcado o radio button SSH em Connection Type. Se tudo
der certo ser pedido o login e o password, digite openflow nos dois. Execute:
$ xterm
Uma nova janela de terminal deve aparecer. Se tiver sucesso ento est feita a
configurao bsica no Windows. Feche o xterm. Caso queira outras janelas de SSH
repita o processo.
6.2.6
Instalando os Editores de Texto
Com todo o processo concludo ser possvel ter total acesso ao VM Mininet pelo
SSH. Instale o seu editor de texto preferido, por exemplo, o vim:
$ sudo aptget install vim
Outro editor recomendado o Gedit, que por sua vez grfico e de fcil utilizao.
Tambm possvel instalar o Eclipse, que uma tima IDE para se trabalhar.
6.2.7
Aprendendo as Ferramentas de Desenvolvimento
Esta seo apresenta o ambiente de desenvolvimento para a fcil familiarizao

das ferramentas utilizadas. So cobertas tanto ferramentas de depurao quanto
ferramentas especficas de OpenFlow.
Definio dos termos, comeando com os tipos de terminais:
terminal da mquina virtual: Este terminal o console criado quando voc iniciou a MV. No possvel copiar e colar neste terminal, nenhuma das aes
com o mouse ter efeito neste terminal, inclusive barras de rolagem. No ser
necessrio o uso deste terminal, uma vez que voc consiga configurar a rede.
terminal SSH: Ele criado a partir do software de SSH, conforme apresentado na
seo anterior. Este terminal utilizado para se conectar ao shell da mquina
virtual. possvel copiar e colar por este terminal alm de ter barra de rolagem
de pelo menos 500 linhas.
68
terminal xterm: Ele utilizado para se conectar a um host da rede virtual. Ele
utilizado dentro do CLI6 do MiniNet para que se possa ter mltiplas janelas para
o desenvolvimento. Ele se conectar a uma elemento da rede virtual.
A VM MiniNet contm uma srie de ferramentas de rede pr-instaladas, sejam
gerais ou especficas do OpenFlow. Algumas delas so:
Controlador OpenFlow: Situa-se acima da interface OpenFlow. A MV contm um
controlador de referncia pr-instalado no ambiente que age como um selflearning Switch Ethernet.
Switch OpenFlow: Situa-se abaixo da interface OpenFlow. A MV contm trs opes de switches para a rede virtual, switches que utilizem o user-space, switches que utilizem o kernel-space e switches que simulam o Open vSwitch j
apresentado na pagina 40.
dpctl: Utilitrio de linha de comando que envia mensagens rpidas do protocolo
OpenFlow, til para visualizar portas de switch e estatsticas de fluxo, alm de
manualmente inserir entradas de fluxo.
Wireshark: Ferramenta grfica geral para a visualizao de pacotes (no especfico de OpenFlow). A distribuio de referncia OpenFlow inclui um Wireshark
dissector, que disseca e analisa as mensagens OpenFlow enviado pela porta
padro do OpenFlow (6633).
iperf: Ferramenta geral de linha de comando para testar a velocidade de uma nica
conexo TCP.
MiniNet A plataforma de simulao de rede que utilizada.
6.2.8
Principais Comandos do MiniNet
Antes de mostrar as principais configuraes para a execuo do CLI do MiniNet,

ser mostrado os principais comando utilizados dentro do CLI do MiniNet. Como j
dito assumimos que esteja utilizando a VM MiniNet.
Para iniciar o CLI do MiniNet no terminal basta executar o comando:
$ sudo mn
Por padro uma topologia minima criada. Essa topologia inclui dois hosts ligados
a um switch OpenFlow por um enlace ethernet e um controlador ligado ao switch.
Em seguinte o CLI do MiniNet estar sendo executado apresentando no terminal:
mininet>
6
Command-line Interface (CLI) um meio de interao com um programa de computador onde o

usurio (cliente) emite comando para um programa na forma de sucessivas linhas de texto (linhas de
comando).
69
Para exibir os comandos do MiniNet, digite no terminal:
mininet> help
Exibir ns:
mininet> nodes
Exibir links
mininet> net
Mostrar informaes sobre todos os ns:
mininet> dump
Se a primeira palavra digitada no CLI do MiniNet for o nome de um n (switch,

host ou controlador), o comando seguinte ser executado por este n. Exemplo:
mininet> h2 ifconfig
Ir apresentar as configuraes de IP do host h2. Outra opo abrir uma janela

de terminal separada para o n desejado, para isso utiliza-se o servidor X. Exemplo:
mininet> xterm h2 h3 s1
Isso ir abrir trs janelas cada uma com o nome correspondente ao seu n. V na
janela com nome switch: s1 (root) e execute:
# dpctl dumpflows tcp: 127.0.0.1:6634
70
Nada ir acontecer, pois o switch ainda no possui entradas de fluxo adicionadas.

Na janela com nome host: h2 (root) e execute:
# ping 10.0.0.3
Voltando a janela com nome switch: s1 (root) execute: # dpctl dumpflows

tcp: 127.0.0.1:6634. Agora sim possvel ver as entradas de fluxo do switch.
O dpctl um ferramenta que vem com a distribuio de referncia OpenFlow
permitindo a visibilidade e o controle sobre uma tabela de fluxos de um nico switch
OpenFlow. Ela muito til para a depurao de redes, pois permite exibio do estado
dos fluxos e dos contadores de fluxo. A maioria dos switches OpenFlow comea com
uma porta de escuta passiva (em sua configurao atual essa porta 6634), na qual
possvel interagir com o switch pela interface OpenFlow, sem ter a necessidade de
adicionar cdigo de debugging no controlador.
Para exibir o estado das portas e capacidades do switch entre no seu terminal
xterm e execute:
# dpctl show tcp:127.0.0.1:6634
Para exibir a tabela de fluxo de um switch entre no seu terminal xterm e execute:
# dpctl dumpflows tcp:127.0.0.1:6634
Para instalar fluxos manualmente em um switch entre no seu terminal xterm e

execute:
# dpctl addflow tcp:127.0.0.1:6634 in_port=1,actions=output:2
Este comando faz uma entrada na tabela de fluxo do switch criando uma regra.
Informa ao switch que os trfegos vindos da porta (entrada) 1 sero encaminhado
para a porta (sada) 2. Note que por padro este regra tem um tempo de validade (60
segundos), caso no haja trfego neste fluxo. Alternativamente podemos modificar
o tempo de validade. Exemplo:
71
# dpctl addflow tcp:127.0.0.1:6634 in_port=1,idle_timeout=120,actions=

output:2
Agora o tempo de validade de 120 segundos. Para maiores detalhes sobre a

ferramenta dpctl execute o comando # dpctl h.
Outro comando utilizado dentro do CLI do MiniNet o:
mininet> iperf
ou
mininet> iperf [fonte] [destino]
O iperf analisa a largura de banda entre dois hosts da rede.

Um comando para teste de alcance entre todos os ns da rede o:
mininet> pingall
O comando pingall faz com que todos os hosts da rede enviem pings7 entre si.
Um comando ltil para teste o comando:
mininet> link [n1] [n2] [up/down]
Este comando desativa ou reativa links entre dois ns. til para testes de depurao.
Para sair do CLI do MiniNet:
mininet> exit
Para maiores detalhes de comando utilizados dentro do CLI do MiniNet visite site
http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet e procure a documentao do MiniNet.
7
PING: um utilitrio que usa o protocolo ICMP para testar a conectividade entre equipamentos.
Seu funcionamento consiste no envio de pacotes para o equipamento de destino e na escuta das
respostas.
72
6.2.9
Comandos Utilizados para a Inicializao do CLI do MiniNet
J conhecendo os principais comandos utilizados dentro do CLI do MiniNet, apresentado ento os comandos utilizados para inicializar o MiniNet (inicializar o CLI),
apresentando as principais opes de inicializao.
Exibir as opes de inicializao (ainda fora do CLI) digite:
$ sudo mn h
Este passo a passo abrangem a maioria dos comandos e opes listadas no uso
das entradas do MiniNet.
Se o MiniNet no estiver funcionando corretamente, apresentando erros tente limpar todo o estado residual ou processos por meio do comando:
$ sudo mn c
Para realizar o teste de ping, afim de testar seu controlador, sem necessitar de
entrar no CLI execute:
$ sudo mn test pingpair
Este comando criar a topologia bsica e far um teste entre todos os pares de
ping, depois do teste ele sai do CLI. Outro comando pra teste :
$ sudo mn test iperf
Este comando tambm cria a topologia bsica e executa o iperf em dois hosts
analisando a largura de banda alcanada.
Como j vimos a topologia padro um nico swtch ligado a dois hosts, no entanto voc pode criar topologias diferentes.
73
$ sudo mn topo single,X

ou
$ sudo mn topo linear,X
ou
$ sudo mn topo tree,X,Y
A primeira cria uma topologia com um nico switch ligados a X hosts, onde X
um nmero. A segunda cria uma topologia linear com X swiches conectados entre
si, ligados cada um a X hosts. A terceira cria uma topologia em rvore de altura X
e com o nmero Y de filhos por n.
Ainda assim possvel criar topologias totalmente diferentes e personalizadas por
meio de uma simples API em Python. Um exemplo fornecido em custom/topo-2sw
-2host.py. Este exemplo cria dois switches, ligados entre si, conectados a um host
cada.
1
" " " Custom topology example
2
3
author : Brandon H e l l e r ( brandonh@stanford . edu )
4
5
Two d i r e c t l y connected s w i t c h e s p l u s a host f o r each s w i t c h :
6
7
host s w i t c h s w i t c h host
8
9
Adding the topos d i c t with a key / value p a i r to generate our newly d e f i n e d

topology enables one to pass i n topo=mytopo from the command l i n e .
"""
10
11
from mininet . topo import Topo , Node
12
13
14
c l a s s MyTopo ( Topo ) :
" Simple topology example . "
15
16
17
def _ _ i n i t _ _ ( s e l f , e n a b l e _ a l l = True ) :
" Create custom topo . "
18
19
20
# Add d e f a u l t members to c l a s s .
super ( MyTopo , s e l f ) . _ _ i n i t _ _ ( )
21
22
23
24
25
26
# Set Node IDs f o r hosts and s w i t c h e s

leftHost = 1
leftSwitch = 2
rightSwitch = 3
rightHost = 4
27
28
29
30
31
32
# Add nodes
s e l f . add_node (
l e f t S w i t c h , Node ( i s _ s w i t c h=True ) )
r i g h t S w i t c h , Node ( i s _ s w i t c h=True ) )
l e f t H o s t , Node ( i s _ s w i t c h=F a l s e ) )
r i g h t H o s t , Node ( i s _ s w i t c h=F a l s e ) )
74
33
34
35
36
37
# Add edges
s e l f . add_edge ( l e f t H o s t , l e f t S w i t c h )
s e l f . add_edge ( l e f t S w i t c h , r i g h t S w i t c h )
s e l f . add_edge ( r i g h t S w i t c h , r i g h t H o s t )
38
39
40
# Consider a l l s w i t c h e s and hosts on

self . enable_all ()
41
42
topos = { mytopo : ( lambda : MyTopo ( ) ) }
codigos/topo2sw2host.py
Veja que muito simples a criao de topologias customizadas, nas linha 23 a 26

temos o exemplo de como podemos criar os ns da rede, podemos colocar qualquer
nome, no entanto temos que identificar um nmero pra cada n. Nas linha 29 a 32
temos os exemplo de como adicionar ns a topologia da rede. Utiliza-se o mtodo
add_node identificando em sua segunda entrada se o n um switch ou no (true/false). Nas linhas 35 a 37 temos o exemplo de como podemos criar as arestas entre
os ns da rede. Utiliza-se o mtodo add_edge identificando os pares de ns que esto interligados. Dessa maneira podemos criar topologias totalmente personalizadas
de acordo com pesquisa.
Para executar o MiniNet com a topologia customizada execute:
$ sudo mn custom /mininet/custom/minha_topologia.py topo mytopo
Neste exemplo o arquivo minha_topologia.py est na pasta /mininet/custom/,

mas pode ficar em qualquer pasta do sistema. A opo mytopo o nome da sua
topologia (veja a linha 42).
Por padro os hosts e switches comeam com endereos MAC aleatrios. Isso
pode tornar dficil a depurao de suas aplicaes de rede, uma vez que cada nova
execuo do MiniNet gera enderes MAC distintos entre seus hosts e switches. Para
resolver este problema podemos utilizar a opo mac em que cada n ter um
endereo simples e de fcil letura. Exemplo:
$ sudo mn mac
O que antes com o comando h2 ifconfig apresentaria um endereo MAC = 7e:7e:

63:3a:6d:c0, agora apresenta um endereo MAC = 00:00:00:00:00:02.
Para abrir um terminal de servidor X para cada n da rede faa:
75
$ sudo mn x
Isso pode ser interessante para realizar teste de monitoramento de pacotes como
por exemplo o tcpdump ou outros testes.
Para tipos de switch por padro 8 utilizado o switch em espao de kernel, no entanto podemos utilizar switch em espao de usurio. Exemplo:
$ sudo mn switch user
Note, no entanto, que a largura de banda nesta opo muito menor, faa o teste
com o iperf. Isso acontece pois os pacote agora precisam atravessar o espao de
usurio para o espao de kernel e voltar a cada salto ao invs de ficar no kernel enquanto atravessam o switch. O switch no espao de usurio mais fcil de modificar
(no necessrio lidar com nenhum kernel), no entanto mais lento na simulao.
Esta opo pode ser interessante como ponto de partida para a implementao
de novas funcionalidades e novas propostas de rede. Outra opo o uso do Open
vSwitch (OVS) que j vm pre-instalado na VM MiniNet. Os testes relatam uma banda
muito semelhante ao switch em espao de kernel. Exemplo:
$ sudo mn switch ovsk
Por padro o controlador executado na simulao o controlador de referncia

controller=ref, isso quando no h nenhum controlador sendo executado na
mquina virtual. Quando h um controlador sendo executado na mquina virtual
o controlador padro o controlador remoto controller=remote. Geralmente
quando se tem um controlador sendo executado na mquina virtual, este foi iniciado pelo o usurio em outra janela SSH, isso ser especificado melhor no prximo
captulo.
Quando especificamos a opo controller=remote sem nenhum controlador
sendo executado, a rede se inicia com um controlador que no realiza nenhuma
ao. Isso tem sentido quando criamos regras manuais para testes especficos com
o comando dpctl add-flow j apresentado anteriormente.
Alternativamente podemos iniciar um controlador remoto localizado fora da VM
MiniNet, pode ser na prpria mquina fsica ou em qualquer outra mquina conectada na internet. Esta opo pode ser conveniente quando se tm alguma verso
personalizada de algum mdulo de um controlador especfico. Exemplo:
8
Na ltima verso estvel do MiniNet, no se utiliza mais os switches em espao de kernel, por
motivos de segurana e incompatibilidades com o sistema. O padro agora utilizado o switch OVS.
76
$ sudo mn controller=remote ip=[ip do controlador] port[porta

de escuta do controlador (padro = 6634)]
No prximo captulo ser apresentado melhor um exemplo de uso dessa opo.
6.3
Outros Comandos e Ferramentas da VM MiniNet
A VM MiniNet possui o OpenFlow Wireshark dissector pr-instalado. O Wireshark

extremamente til para a anlise de mensagens do protocolo OpenFlow bem como
depurao de um modo geral. Para iniciar o Wireshark crie uma nova janela SSH e
certifique-se que ela executar o servidor X, explicado anteriormente.
O comando para abrir o Wireshark :
$ sudo wireshark &
Voc provavelmente vai receber uma mensagem de aviso por usar o Wireshark
com acesso root. Ignore o aviso e pressione OK. Clique em CaptureInterfaces no
menu. Abrir uma nova janela e clique no boto Start ao lado da interface lo.
Neste momento ser apresentado uma lista com diversos pacotes em constante
incremento. Crie um filtro para controle do trfego OpenFlow. Na caixa de filtro
coloque of e pressione apply para filtrar o trfego OpenFlow.
Primeiro execute o MiniNet com um controlador remoto:
$ sudo mn controller=remote
Agora inicie o controlador de referncia em outra janela SSH:
$ controller ptcp:
Isso inicia um controlador simples, que atua como um learning switch sem instalar
nenhuma entrada na tabela de fluxo.
Ser exibida diversas mensagens Wireshark, comeando com Hello. Clique em
Features Reply. Abrir uma nova janela, clique no triangulo ao lado de OpenFlow
Protocol para exibir os campos de mensagens. Clique em no triangulo ao lado de
77
Switch Features e veja as capacidades do datapath. Sinta-se a vontade, explore

os recursos do Wireshark.
Quadro 6.1: Tipos de mensagens OpenFlow apresentadas ao iniciar o controlador.
Mensagem
Hello
Tipo
ControladorSwitch
Hello
SwitchControlador
Features Request ControladorSwitch

Set Config
ControladorSwitch
Features Reply
SwitchControlador
Port Status
SwitchControlador
Descrio
aps o TCP handshake, o controlador
envia seu nmero de verso para o
switch.
o switch responde com seu nmero de
verso suportado.
o controlador pede ao switch para ver
quais portas esto disponveis.
O controlador pede ao switch para enviar expiraes de fluxo
as respostas do switch com uma lista
de suas portas e outras caractersticas.
permite ao switch informar ao controlador mudanas de velocidades de
porta ou de conectividade. Ignorar
este, pois parece que est com problemas nesta verso do OpenFlow.
Quando h muitos switches, a anlise do Wireshark pode ficar um pouco confusa,

pois varias mensagens repetidas vo aparecer. Mas isso no acontece quando criamos a topologia com um nico switch. Note que as mensagens de Echo Request/Echo
Reply so mensagens para manter a conexo entre os switches e o controlador ativas.
Agora vamos ver as mensagens geradas em pings na rede. Modifique seu filtro
no Wireshark:
of && (of.type != 3) && (of.type != 2)
Agora na janela do MiniNet execute um ping:
mininet> h2 ping -c1 h3
Na janela Wireshark, possvel ver uma srie de novos tipos de mensagens:

Primeiro vemos a mensagem Packet-In com uma requisio ARP. Logo depois
vemos a mensagem Packet-Out que corresponde a ao tomada pelo controlado no
switch, esta ao no caso o envio em broadcast pelas portas do switch com exce78
Quadro 6.2: Tipos de mensagens OpenFlow apresentadas ao realizar um ping.

Mensagem
Packet-In
Tipo
SwitchControlador
Packet-Out
ControladorSwitch
Flow-Mod
ControladorSwitch
Flow-Expired SwitchControlador
Descrio
o pacote foi enviado ao controlado pois
no possui uma entrada correspondente a esse pacote na tabela de fluxo
do switch.
controlador envia um pacote de uma
ou mais portas do switch.
adiciona uma entrada na tabela de
fluxo do switch.
um fluxo expirou aps um perodo de
inatividade.
o a porta que chegou o pacote. Quando o pacote de resposta chega ao switch este
j conhece o caminho para h2 e neste momento ele envia a mensagem Flow-Mod
criando uma entrada na tabela de fluxo do switch. Nos prximos pings, no h envolvimento do controlador, a exibio das mensagens no Wireshark devem parar por
ai at a validade do fluxo vencer e apresentar a mensagem Flow-Expired.
Caso tenha qualquer outra dvida ou dificuldade em de utilizar o Wireshark procure pela documentao em http://www.wireshark.org/.
Outra possibilidade interessante no uso do MiniNet a possibilidade de se executar scripts em um host, dentro do CLI ou em sua inicializao. Voc pode executar
em um host. Exemplo:
mininet> h2 config_script
Ou mesmo ser utilizada no prprio CLI:
mininet> source my_cli_script
Ou utiliz-la na inicializao do CLI:
$ sudo mn pre my_cli_script
Todas esses comandos evita a digitao repetitiva no CLI em seus testes e depuraes de sua aplicao de rede. possvel criar um arquivo com mltiplos comandos
79
do CLI para determinado fim especfico. Note que nos exemplos acima o arquivo deve
ficar na pasta raiz do MiniNet, no entanto pode-se especificar o local no comando.
Um exemplo de um script apresentado a seguir:
py Configuring network
h3 ifconfig h3-eth0 10.0.1.2/24
h3 route add default gw 10.0.1.1
py Current network:
net
dump
O MiniNet tambm fornece APIs para a criao e a configurao de Redes Definidas por Software. Alguns exemplos de uso pode ser encontradas em mininet/examples,
suas descries encontram-se em mininet/examples/README. Destaca-se duas APIs
grficas, no muito utilizveis mais que consistem em ideias interessantes. Exemplo:
$ sudo ./ mininet/examples/miniedit.py
Abrir uma janela grfica com a qual possvel desenhar uma topologia de maneira simples e fcil, no entanto essa API no funcional e no possvel se fazer
absolutamente nada com ela, feche-a e ela encerrar o CLI do MiniNet (Figura 6.1).
Outro exemplo :
$ sudo ./ mininet/examples/consoles.py
Abrir uma janela grfica com uma grade de janelas de console, uma para cada
n, e permite a interao com o acompanhamento de cada console, incluindo monitorao com um grfico e comandos como o iperf, pings (Figura 6.2).
Tambm possvel criar APIs prprias para MiniNet. Uma API simples basicamente utiliza-se das bibliotecas mininet.net, mininet.node, mininet.cli. A primeira
contm os mdulos necessrios para se montar a rede virtual propriamente dita, a
segunda por sua vez contm os mdulos para se criar todos os ns virtuais dessa
rede e a terceira serve para que se possa executar o CLI do MiniNet. A seguir apresentada uma API simples com comentrios.
80
Figura 6.1: MiniNet API miniedit.py.
Figura 6.2: MiniNet API consoles.py.
1
2
3
4
5
"""
Este e o exemplo de como c r i a r uma API simples i n s t a n c i a n d o um o b j e t o
MiniNet
montando sua t o p o l o g i a e executando o C L I
"""
# importando as c l a s s e s n e c e s s a r i a s
6
7
8
9
10
from
from
from
from
mininet . net import M i n i n e t

mininet . node import C o n t r o l l e r
mininet . c l i import C L I
mininet . l o g import setLogLevel , i n f o # para informacoes de l o g
11
12
def minhaAPI ( ) :
13
14
# Criando a rede :
81
15
net = M i n i n e t ( c o n t r o l l e r=C o n t r o l l e r ) # i n s t a n c i a n d o um o b j e t o da
classe Mininet
16
17
18
i n f o ( Adding c o n t r o l l e r \ n ) # imprimindo l o g i n f o
net . a d d C o n t r o l l e r ( c0 ) # adicionando um c o n t r o l a d o r
19
20
21
22
i n f o ( Adding
h1 = net . addHost (
colocando seu
h2 = net . addHost (
hosts \ n )
h1 , i p= 1 0 . 0 . 0 . 1 ) # adicionando um no host e
ip
h2 , i p= 1 0 . 0 . 0 . 2 )
23
24
25
i n f o ( Adding s w i t c h \ n )
s3 = net . addSwitch ( s3 ) # adicionando um s w i t c h openflow
26
27
28
29
i n f o ( C r e a t i n g l i n k s \ n )
h1 . l i n k T o ( s3 ) # c r i a n d o o l i n k de h1 ( host1 ) para s3 ( s w i t c h openflow )
h2 . l i n k T o ( s3 )
30
31
32
i n f o ( S t a r t i n g network \ n )
net . s t a r t ( ) # i n i c i a n d o a rede
33
34
35
i n f o ( Running C L I \ n )
C L I ( net ) # i n i c i a n d o o C L I com a rede c r i a d a
36
37
# o codigo para aqui ate que se s a i a do C L I
38
39
40
i n f o ( Stopping network )
net . stop ( ) # para a rede c r i a d a
41
42
43
44
i f __name__ == __main__ :
setLogLevel ( i n f o )
minhaAPI ( )
Para executar esta API, crie um arquivo com o nome de minhaAPI.py no diretrio
mininet/examples e execute-o na mquina virtual da seguinte maneira:
$ sudo python -O /mininet/examples/minhaAPI.py
Pode-se criar APIs de diversas maneiras. Este trabalho contribui com a criao de
uma APIs de inicializao do MiniNet com interface grfica. Foi utilizando a biblioteca
Tkinter do Python (Figura C.1). Seu cdigo pode ser visto no Apndice C.
6.4
Teste o Simulador
Agora que se sabe como executar o MiniNet, se conhece os principais comandos

utilizados dentro do CLI e se conhece quais as principais opes de inicializao do
82
CLI, possvel utiliz-los em conjunto, misturando os diversos tipos de opes na

inicializao, por exemplo:
$ sudo mn custom /mininet/custom/topo-2sw-2host.py topo mytopo

mac switch ovsk controller remote ip=10.0.2.2 port=6634
pre /mininet/custom/my_cli_script
Caso tenha alguma dvida consulte a documentao em: http://yuba.stanford.

edu/foswiki/bin/view/OpenFlow/MininetDocumentation.
83
Captulo 7
Implementaes Desenvolvidas
Entendendo a estrutura do POX e do MiniNet, agora possvel desenvolver componentes no POX e utiliz-los no MiniNet. Para se fazer isso necessrio ter instalado
o MiniNet conforme apresentado no Captulo 6 e ter instalado o POX na prpria mquina virtual VM MiniNet (recomendado) ou em uma mquina que esteja hospedando
a mquina virtual VM MiniNet.
Este captulo mostra como instalar o POX e como desenvolver componentes funcionais em vrios cenrios de redes. Com as implementaes desenvolvidas neste
captulo o pesquisador poder entender melhor como funciona a estrutura de uma
rede SDN podendo ento implementar seus prprios componentes que atendam seus
requisitos de pesquisa.
Os cdigos das implementaes desenvolvidas neste captulo foram utilizados no
simulador MiniNet, mas poderiam ser aplicados em redes SDN reais, equivalentes as
simuladas, sem a necessidade de adaptaes.
7.1
Instalando e Configurando o POX
Para instalar o POX abra um terminal no computador (Linux ou MAC) ou uma janela SSH conectada a mquina virtual VM MiniNet (preferencialmente se for usar
Windows) e baixe o cdigo do POX no repositrio do POX no GitHub dessa forma:
$ git clone http://github.com/noxrepo/pox

$ cd pox
Caso queira utilizar a verso beta faa:
/pox$ git checkout betta
84
Pronto, o POX est instalado. Navegue por suas pastas para entender melhor sua
estrutura, apresentada no Captulo 5. A verso beta a mais atual verso do POX e
est em constante modificao pelos desenvolvedores.
7.2
Executando um Componente do POX no MiniNet
Agora que o MiniNet e POX esto instalados, abra dois terminais, um para o POX
e outro para o MiniNet (Se o POX estiver instalado na maquina virtual VM MiniNet
devero ser abertos dois terminais SSH).
No terminal SSH da mquina virtual VM MiniNet feche todos os controladores:
$ sudo killall controllers
Depois limpe o MiniNet com o comando:
$ sudo mn c
Se o POX estiver instalado na mquina hospedeira do VM MiniNet execute o comando a seguir para identificar o IP da mquina hospedeira, caso contrrio pule esta
etapa.
$ sudo route
Ir aparecer algo como:

1
2
3
4
5
Kernel IP routing table

Destination
Gateway
default
10.0.2.2
10.0.2.0
192.168.56.0
Genmask
0.0.0.0
255.255.255.0
255.255.255.0
Flags
UG
U
U
Metric
0
0
0
Ref Use I f a c e
0
0 eth1
0
0 eth1
0
0 eth2
Procure a linha que comea com default e anote o endereo IP da coluna Gateway.
Para iniciar o MiniNet execute o comando a seguir, se o POX estiver sido instalado
na VM MiniNet (recomendado) apague a opo ip.
85
$ sudo mn topo single,3 mac switch ovsk controller=remote

ip=[endereo ip anotado]
Caso o endereo anotado termine com .1 no ser possvel se conectar com um

controlador remoto fora da VM MiniNet, substitua o .1 por .2. Pronto a rede SDN
virtual est criada e o POX poder conectar-se a ela remotamente em uma mquina
hospedeira ou na prpria mquina virtual VM MiniNet (recomendado).
No terminal destinado ao POX entre no diretrio pox/ (cd pox) e execute algum
componente do POX (seo 5.3), por exemplo o forwarding.l2_learning da seguinte
maneira:
$./pox.py log.level DEBUG forwarding.l2_learning
Se tudo correr bem ser possvel executar um pingall com sucesso no terminal do MiniNet. Pronto, a rede est funcionando e o componente l2_learning est
controlando essa rede com sucesso. J ser possvel executar aquele componente
criado na Seo 5.12 e entender melhor seu funcionamento. A prxima seo explicar qual o cenrio foi criado neste exemplo e quais os cenrios e componentes que
sero criados.
7.3
Cenrios de Simulao
Na seo anterior foi criada a rede virtual SDN e executado um componente pronto
do POX. O cenrio criado na seo anterior ser o mesmo cenrio que ser utilizado
nos dois primeiros componentes (HUB e SWITCH).
Este cenrio consiste de um nico switch OpenFlow (s1) ligado a trs hosts (h2,
h3, h4) como mostra a Figura 7.1.
O segundo cenrio que ser apresentado consistir de trs switches OpenFlow
(s5, s6, s7) ligados em rvore nos quais os dois switches finais (folha da rvore)
tero dois hosts cada (h1, h2, h3, h4). Este cenrio ser utilizado no terceiro e quarto
componente (SWITCHES, FIREWALL). Este cenrio pode ser visto na Figura 7.2.
O terceiro e ltimo cenrio tambm ter trs switches OpenFlow (s0, s1, s2) s
que dessa vez interligados entre si funcionando como roteadores, nos quais cada um
ter sua rede composta por dois hosts ([h0, h1], [h2, h3], [h4, h5]). Utilizaremos este
cenrio para o quinto e sexto componente (ROUTER, Especifico). Este cenrio pode
ser visto na Figura 7.3.
Os componentes sero especificados nas prximas sees.
86
Figura 7.1: Primeiro Cenrio de Testes.
Figura 7.2: Segundo Cenrio de Testes.
7.3.1
Componente HUB
Esta seo apresenta como construir um componente que age como um HUB,
replicando os pacotes recebidos e enviado para todas as suas portas de sada. Para
este componente ser utilizado o primeiro cenrio. interessante observar como
estruturado um componente no POX e como o POX trabalha com os pacotes e as
mensagens OpenFlow. No Apndice B na seo B.2 apresentado o cdigo deste
componente com comentrios.
O componente inicia-se no mtodo launch e registra um ouvinte de mensagens
do ncleo do POX. No registrado nenhuma classe ou mtodo no ncleo do POX,
como nos exemplos anteriores, apenas utiliza-se do mtodo addListenerByName j
registrado no ncleo do POX pelo mdulo openflow, executado automaticamente,
para ouvir as mensagens do tipo ConnectionUp1 da rede. Quando essas mensagens
chegam, executado o mtodo start_switch que recebe o evento da conexo com
o comutador, e a partir da instanciado a classe HUB.
1
Essa mensagens so enviadas ao controlador quando um comutador entra na rede
87
Figura 7.3: Terceiro Cenrio de Testes.

A classe HUB por sua vez inicia a conexo com o comutador e registra tratadores (handle) de mensagens OpenFlow por meio do mtodo addListeners. Dessa
forma possvel ouvir as mensagens PacketIn2 vindas ao controlador. Assim quando
o comutador recebe pacotes, que no possuem entradas em sua tabela de fluxo,
ele os envia ao controlador, que no caso deste componente faz as aes que o
mtodo _handle_PacketIn faz. Neste componente este mtodo chama o mtodo
act_like_hub para que o comutador haja como um hub.
Para testar este componente, basta criar o arquivo citado dentro da pasta pox/ext
com o nome hub.py e executar da seguinte maneira:
$ ./pox.py log.level DEBUG hub
Na VM MiniNet em um terminal SSH, cria-se a rede (primeiro cenrio):
$ sudo mn topo single,3 mac switch ovsk controller=remote

ip=[endereo ip do host]
Caso o POX seja executado na prpria VM MiniNet, como recomendado, basta

remover a opo ip. Execute testes no CLI do MiniNet como ping, pingall ou
iperf, veja o comportamento dos pacotes com o WireShark (Seo 6.3).
2
Mensagens que o controlador recebe quando o comutador recebe um pacote que no tem entradas em sua tabela de fluxo
88
7.3.2
Componente SWITCH
Este componente haje como um switch de auto aprendizagem de camada dois

que aprende o caminho a medida que os pacotes chegam no comutador. Em outras
palavras um simples switch que aprende os caminhos de seus hosts. No Apndice B
na seo B.3 apresentado o cdigo deste componente com comentrios.
O interessante deste componente observar como se trabalha com mensagens
ofp_flow_mod que instala entradas na tabela de fluxo de um comutador OpenFlow.
Esse tipo de comportamento faz com que o switch execute o comutamento de pacotes muito mais rpido do que o componente anterior.
No HUB as mensagens enviadas eram do tipo ofp_packet_out, que so mensagens utilizadas pelo que o controlador para instruir o switch aonde enviar os pacotes.
Esse tipo de comportamento pior em relao ao desempenho, pois o controlador
participa da deciso de encaminhamento de todos pacotes que chegam no switch.
Este componente semelhante ao anterior quanto a sua estrutura, a diferena
que quando os pacotes chegam ao controlador, e no possuem entradas na tabela de
fluxo referente a este pacote, o componente anota o endereo fsico (MAC) da fonte
do pacote em uma tabela e associa este endereo a porta de chegada do switch
(linha 26), em seguida verificado se o endereo de destino fsico do pacote est
nessa tabela, se estiver, ser instalado o fluxo no comutador, se no estiver na tabela
ele instrui o comutador a inundar o pacote em todas as demais portas, como o HUB
faz. Sempre que um novo pacote passar pelo switch, a dupla formada pela porta de
entrada e MAC de origem ser gravada na tabela, caracterizando o mecanismo de
auto-aprendizagem.
com o nome switch.py e executar da seguinte maneira:
$ ./pox.py log.level DEBUG switch
O componente pode ser testado no cenrio de teste do componente anterior.

Execute testes no CLI do MiniNet como ping, pingall ou iperf veja a diferena do
resultado deste ltimo. Veja o comportamento dos pacotes com o WireShark e os
tipos de mensagens OpenFlow.
7.3.3
Componente SWITCHES
O componente anterior funciona apenas em cenrios de rede com um switch. Isso

ocorre pois a tabela em que se anota os endereos fsicos e suas portas de origem
uma tabela global do componente, logo quando se h mais do que um switch essa
tabela no faz sentido, pois portas iguais de diferentes switch podem encaminhar
pacotes para lugares diferentes na rede. No Apndice B na seo B.4 apresentado
o cdigo deste componente com comentrios.
Faz-se necessrio ento anotar tambm os nmeros de identificao de cada
switch nesta tabela global, para que quando o pacote for comparado na tabela, este
89
deve ser comparado com o switch que questiona o controlador sobre o caminho de
pacotes (_handle_PacketIn). Alternativamente pode-se colocar uma tabela exclusiva para cada switch quando estes instanciam a classe Switch (linha 75). O prximo
componente faz isso.
com o nome switches.py e executar da seguinte maneira:
$ ./pox.py log.level DEBUG switches
Na VM MiniNet em um terminal SSH, cria-se a rede (segundo cenrio):
$ sudo mn topo tree,2 mac switch ovsk controller=remote

ip=[endereo ip do host]
Caso o POX seja executado na prpria VM MiniNet, como recomendado, basta

remover a opo ip. Execute testes no CLI do MiniNet como ping, pingall ou
iperf, veja o comportamento dos pacotes com o WireShark.
7.3.4
Componente FIREWALL
Este componente mostra como possvel instalar regras especificas nos switches
para que hajam como um firewall ou mesmo negando servios especficos. O proposito deste componente mostrar como possvel criar regras especificas para os
comutadores da rede. No Apndice B na seo B.5 apresentado o cdigo deste
A estrutura do componente segue o mesmo padro dos outros. A diferena est
na tabela que guarda os valores dos endereos fsicos e portas, dessa vez ela no
e global, e por esse motivo no se faz mais necessrio guardar o ID do switch, pois
cada switch ter sua tabela quando instanciar a classe (linha 137).
Assim que um switch se conecta na rede gerado uma mensagem de ConnectionUp
que faz com que o switch instancie a classe Firewall que na sua inicializao cria a
tabela MAC/PORT (linha 20) e chama o mtodo install_firewall_rules que instala
regras determinadas no switch.
Essa regras foram definidas como exemplo para este cenrio, poderiam ser feitas
outras regras ou de maneiras diferentes. A primeira regra faz com que pacotes que
tenham a porta TCP 80 sejam enviados ao controlador, para que ele decida o que
fazer. A segunda regra envia todos os pacotes que tenha o IP de destino igual a
10.0.0.2 para o controlador. Em ambos os casos os switches enviam esses pacotes
por meio de uma mensagem PacketIn ao controlador. Este, por sua vez, decidir o
caminho no mtodo _handle_PacketIn do componente utilizado (linha 58), que neste
exemplo retorna sem realizar ao alguma.
90
Dessa forma pacotes que tenham a porta TCP 80 e pacotes que tenham o endereo de destino IP 10.0.0.2 no sero comutados nessa rede. Para testar este componente, basta criar o arquivo citado dentro da pasta pox/ext com o nome firewall.py
e executar da seguinte maneira:
$ ./pox.py log.level DEBUG firewall
O cenrio de teste utilizado neste componente o mesmo cenrio do componente

anterior. Execute testes no CLI do MiniNet como ping, pingall ou iperf. Para testar
se os pacotes com a porta TCP 80 sero comutados, abra um xterm para dois ns
(Ex.: xterm h1 h3) e faa em um deles:
# iperf -s -p 80
No outro n faa:
# iperf -c [endereo ip do outro n] -p 80
possvel ver que o trafego no ir fluir, fazendo o teste com outra porta possvel
ver que fluir normalmente. necessrio observar que, neste cenrio especifico,
pacotes com destino ao h2 no chegaro, logo pings a h2 ou oriundos de h2 tambm
no funcionaram. Para maiores detalhes veja o comportamento dos pacotes com o
WireShark.
7.3.5
Componente ROUTER
Este componente um pouco mais complexo que os outros. Ele utiliza o terceiro
cenrio. Seu cenrio composto de trs sub-redes com os seguintes endereos IP:
10.0.1.1/24, 10.0.2.1/24 e 10.0.3.1/24 com a mascara de sub-rede 255.255.255.0.
Para criar esta rede, pode-se utilizar os mtodos apresentados no Captulo 6, pgina 75. Para configurar os IPs da rede e o gateway pode-se utilizar o comando
ifconfig com as opes necessrias. Alternativamente possvel criar a topologia no MiniNet executando o cdigo apresentado no Apndice B na seo B.1 com
comentrios. O cdigo deste componente encontra-se no Apndice B na seo B.5.
Este componente deve implementar o protocolo de roteamento ARP3 na rede anotando em uma tabela (linha 35), para cada switch, o endereo fsico (MAC) da fonte
3
Address Resolution Protocol ou ARP um protocolo usado para encontrar um endereo da

camada de enlace (MAC) a partir do endereo da camada de rede (IP).
91
com seu endereo rede (IP) e sua porta de chegada. Com essas informaes possvel rotear os pacotes na rede.
Quando um switch se conecta na rede ele instancia a classe Router que inicia duas
tabelas, uma ARP (linha 35) e outra de IP (linha 42). A primeira a tabela usada no
protocolo ARP, j a segunda serve para anotar os IPs que j passaram neste switch.
Essa tabela serve para garantir que IPs que no existem na rede no fiquem sendo
inundados pelo protocolo APR em um lao sem fim.
Quando pacotes chegam ao comutador verificado se este pacote do tipo ARP
ou IP. Se for ARP executado o mtodo arp_responder (linha 45) que executa o protocolo de roteamento ARP, se for IP executado o mtodo route (linha 124) que faz
o roteamento de pacotes de acordo com a tabela ARP. Para testar este componente,
basta criar o arquivo citado dentro da pasta pox/ext com o nome router.py e executar da seguinte maneira:
$ ./pox.py log.level DEBUG router
O componente pode ser testado no terceiro cenrio de teste j apresentado. Execute testes no CLI do MiniNet como ping, pingall ou iperf e veja os resultados. Veja
o comportamento dos pacotes com o WireShark e os tipos de mensagens OpenFlow.
7.3.6
Componente ESPECFICO
Este componente um exemplo de como controlar o funcionamento da rede de

uma maneira bem especfica. Pode servir como base para entender as funcionalidades do OpenFlow usando o controlador POX. Agora que j foi apresentado os componentes anteriores, este componente torna-se bem simples de entender. Seu cenrio
de teste o cenrio do componente anterior e s funcionar neste cenrio configurado dessa maneira. No Apndice B na seo B.7 apresentado o cdigo deste
Cada pacote que chega ao controlador inspecionado e atribudo a ele uma rota,
dando uma entrada na tabela de fluxo do comutador. Dessa forma, cada pacote novo
que chega ao switch enviado ao controlador onde o mtodo _handle_PacketIn os
recebe e chama o mtodo install_rules que instala uma regra para este pacote de
acordo com uma lgica definida.
O funcionamento do fluxo de pacotes nesse componente funciona da seguinte
maneira:
1 - O enlace que liga os switches s0 e s1 exclusivo para pacotes que tenham a
porta de destino e de origem TCP 1234, nenhum outro pacote deve passar por
esse enlace.
2 - Todos os demais pacotes so comutados normalmente na rede sem passar no
enlace que liga diretamente os switches s0 e s1.
Com essas regras na rede, os pacotes que tenham portas TCP 1234 iro ter prioridade na comutao de pacotes entre os switches s0 e s1 j que todos os outros
92
pacotes devero passar por s2. Este caso e todos os outros servem como exemplo
de como controlar uma rede SDN utilizando o POX.
com o nome especifico.py e executar da seguinte maneira:
$ ./pox.py log.level DEBUG especifico
O componente s poder ser testado no cenrio de testes do componente anterior. Execute testes no CLI do MiniNet como ping, pingall ou iperf e veja os resultados. Analise os resultados do iperf com a porta TCP 1234 e com outras portas
nos diversos ns. Veja o comportamento dos pacotes com o WireShark e os tipos de
mensagens OpenFlow.
7.4
Resultados Esperados
Neste captulo foi desenvolvido alguns componentes no POX e foram utilizados

e testados na plataforma de simulao de Redes Definidas por Software, o MiniNet.
Esses componentes servem como base para a criao de cenrios de testes em redes
reais para o paradigma de Redes Definidas por Software.
possvel agora observar na prtica como funciona o protocolo OpenFlow, como
funciona a troca de mensagens entre os comutadores e o controlador, alm claro
de entender a estrutura de um controlador de rede SDN e poder utiliz-lo para o
controle de uma rede SDN.
necessrio entender o funcionamento do POX antes de iniciar a execuo destes
componentes. Alm disso, necessrio entender o funcionamento do MiniNet para
testes em ambientes simulados. A partir de ento possvel implementar estes
componentes em ambientes reais com comutadores e hosts fsicos.
Com a compreenso desses componentes possvel implementar diversos casos
particulares para testes de novas pesquisas na rea de redes, ou mesmo para o
uso como ferramenta didtica em disciplinas de redes. Apresentar os conceitos e
protocolos de redes de computadores por meio de ferramentas como o MiniNet, traz
para o aluno uma viso programtica de como os desafios so resolvidos no ncleo
da rede. Alm disso, ao possibilitar que o aluno experimente um protocolo, ou ainda,
permitir que ele possa estend-lo adicionando novas funcionalidades, o educador
estar preparando seus alunos para os desafios reais das redes de computadores.
93
Captulo 8
Discusso e Concluso
As redes de computadores constituem, hoje, um servio de primeira necessidade
para a sociedade. No entanto, os mesmos motivos que a mantiveram at hoje, sua
arquitetura baseada no servio de transferncia fim-a-fim e a pilha de protocolos
TCP/IP, tambm so responsveis pelas limitaes vivenciadas hoje no tangente a
escalabilidade, mobilidade e gerenciamento. Contudo, para atender tais servios, as
redes de computadores foram evoluindo por meio de adaptaes, funcionalidades
estas no previstas em sua arquitetura original. Essas adaptaes dificultaram
e inibiram a criao de novas propostas de arquiteturas para seu ncleo, visto que
essas propostas devem ser compatveis com as adaptaes da rede no afetando o
funcionamento da mesma. Estudos argumentam pela necessidade de se desenvolver
uma nova arquitetura para a Internet, a Internet do Futuro [2, 17].
Os diversos estudos voltados para a Internet do Futuro apontam para um modelo
pluralista, na qual a infraestrutura de rede deve ser capaz de dar suporte a diversas
redes em paralelo, cada uma com sua pilha de protocolos e gerenciamento prprio,
garantindo alta flexibilidade e permitindo a inovao no ncleo da rede. Uma tecnologia que permite o desenvolvimento desse modelo a virtualizao de redes. A
virtualizao de redes consiste no desenvolvimento de uma camada de abstrao
sobre a infraestrutura fsica da rede. Essa tecnologia, utilizada em projetos como a
GENI [26], prope uma nova forma de organizar as redes de computadores, utilizando
mquinas virtuais para representar comutadores virtuais na rede. Entretanto, esse
tipo de virtualizao enfrenta o desafio de se obter uma implementao eficiente
do plano de dados nos comutadores, uma vez que nas redes atuais a otimizao do
hardware de encaminhamento de pacotes atingiu patamares de desempenho significativos, impossveis de se equiparar em software.
Nesse contexto, o paradigma de Redes Definidas por Software (SDN) surge como
uma alternativa para o desenvolvimento do modelo de virtualizao de redes. Por
darem acesso s tabelas de encaminhamento de forma programvel, as redes SDN
oferecem uma nova forma de virtualizar a rede, no mais com mquinas virtuais
independentes para cada elemento da rede virtual, mas com o particionamento dos
espaos de endereamento dessas tabelas. Dessa forma, vises abstratas da rede
podem ser oferecidas a cada operador que deseje implementar um novo servio
sobre a rede fsica.
94
8.1
Desafios de Pesquisa
O paradigma SDN considerado o modelo mais promissor de arquitetura para a

Internet do Futuro [14]. Sua capacidade de implementao gradual na arquitetura
de rede um dos principais motivos que o tornam o modelo eleito pela academia e
industria, alm do fato de prover uma viso global e o gerenciamento centralizado
da rede.
O paradigma SDN abre uma gama de novas possibilidades para a pesquisa em
redes de computadores. A Seo 3.7 apresentou diversos contextos de aplicao que
podem oferecer novos enfoques e possibilidades de evoluo. Deve-se considerar
que o paradigma SDN ainda algo novo e, portanto, existe um longo caminho para
consolidar este paradigma.
Pode-se classificar alguns dos principais desafios, conforme tratado a seguir:
A viso da rede - O paradigma SDN prov uma viso global da rede disponvel pelo
controlador da rede. Os controladores atuais ainda no apresentam essa viso
como um elemento de sua estrutura bsica, ela pode ser constituda com base
nas informaes derivadas das mensagens recebidas. Espera-se que os controladores ofeream esse elemento por meio da noo do Modelo de Objetos
da Rede, ou Network Object Model (NOM) [14]. Essa abstrao permitir o
desenvolvedor de aplicaes SDN implementar o controle de aes em funo
do grafo de rede e no mais ao redor dos eventos de chegada de mensagens
OpenFlow.
Sistema operacional de Redes - A noo do sistema operacional de rede como
um ambiente de execuo que estabelece a ligao entre as aplicaes SDN
e a rede fsica pode ir alm das implementaes de um controlador de rede
SDN atual. Este conceito pode abrir caminhos para uma nova forma de se pensar em redes de computadores, no mais em termos de artefatos tecnolgicos,
mas de princpios organizacionais abstratos como ocorre na rea de Sistema
Operacionais. Pode-se utilizar questes como escalonamento de processos, algortimos de sincronizao e estruturas de dados como princpios bsicos para
essa nova gerao de controladores de rede, fazendo com que eles realmente
se comportem como sistemas operacionais.
O encaminhamento - Apesar do OpenFlow ser apresentado como a principal interface de acesso aos mecanismos de encaminhamento de cada comutador, as
redes SDN no se restringem a ele. Solues deveriam oferecer uma interface
de encaminhamento pela malha da rede, independentemente da interface particular de cada elemento. Assim, aplicaes poderiam se concentrar em suas
caractersticas especficas, fazendo uso de primitivas de encaminhamento fima-fim na rede.
Depurao - A incluso que o paradigma SND traz de ter diversos nveis de abstrao entre as aplicaes de rede e sua infra-estrutura fsica, cria a necessidade
de regras que traduzam o que expressado na linguagem e interface de aplicaes e como os conceitos associados so implementados na rede fsica. Nesse
95
processo, existe a possibilidade de que a configurao da rede fsica no represente o que era previsto nos nveis superiores. Criar mecanismos que possam
identificar quando isso ocorre, e qual sua causa, ainda um problema em
aberto nos mecanismos de depurao do paradigma SDN.
Distribuio - A forma de controle centralizado que o paradigma SDN oferece no
precisa, necessariamente, ser implementada de forma centralizada. Dessa
forma, projetos de controladores distribudos fisicamente mas centralizados logicamente ainda so possveis linhas de pesquisa que podem ser exploradas
nesse contexto. Vale lembrar que a noo de viso global da rede como algo
centralizado em SDN uma viso lgica e o paradigma no exige que essa
viso deva ser, obrigatoriamente, implementada de forma centralizada. Requisitos de desempenho ou tolerncia a falhas poderiam levar a decises de
distribuio dessa viso.
8.2
Consideraes Finais
Foi observado que o paradigma de Redes Definidas por Software uma grande
promessa para a arquitetura da Internet do Futuro. Seu potencial apenas est comeando a ser explorado, mas j grande o interesse da rea acadmica e da industrial.
O fato de existirem no mercado diversos dispositivos comerciais com o protocolo
OpenFlow habilitado confirma que esse paradigma bastante promissor.
Este trabalho apresentou o contexto histrico das redes de computadores, sua
infraestrutura e seus problemas para atender todos os requisitos hoje estabelecidos
pelas novas aplicaes de rede. Foi observado que a arquitetura atual das redes de
computadores est saturada e tm dificuldades para atender as novas demandas do
mercado. Embora sejam identificadas muitas propostas de rede para atender esses
requisitos, estas no so bem aceitas no mercado comercial por no serem testadas
em ambientes reais. Isso deve-se ao fato das redes atuais estarem ossificadas com
diversas adaptaes em sua arquitetura original. A comunidade acadmica estuda
formas de renovar essa arquitetura, com as propostas de Internet do Futuro. Dentre
os estudos mais promissores est o paradigma de Redes Definidas por Software.
O presente trabalho buscou apresentar uma viso dos aspectos tericos e prticos
envolvidos no desenvolvimento de pesquisas em Redes Definidas por Software, apresentando suas caractersticas e elementos essenciais para o desenvolvimento nessa
rea, com nfase no controlador de rede. O controlador de rede o elemento que
tem o papel essencial em qualquer iniciativa SDN, uma vez que o software que define
as redes so desenvolvidos com base nos recursos oferecidos. Diversas opes de
controladores foram descritas e algumas aplicaes bsicas foram apresentadas no
texto. O OpenFlow, que consiste na principal interface associada ao paradigma SDN,
foi apresentado e descrito. Suas caractersticas formam um dos elementos mais motivadores para o paradigma apesar de no ser a nica forma de se implementar uma
SDN. Foi, ento, apresentado o POX, um controlador recentemente lanado e especialmente desenvolvido para o ambiente de pesquisa e ensino. Com a modelagem
96
e estrutura apresentadas se torna fcil desenvolver e construir aplicaes SDN que

utilizem a interface OpenFlow.
O cenrio de testes utilizado foi feito por meio do simulador de Redes Definidas
por Software MiniNet. Vale ressaltar que os testes desenvolvidos no texto podem
ser utilizados em redes fsicas reais. mostrado como implementar componentes
no POX e como test-los no MiniNet. Todos as implementaes desenvolvidas neste
trabalho servem como base para pesquisa e modelagem de ensino na rea de redes
de computadores.
Considerando o sucesso do paradigma SDN e todos os desafios identificados neste
texto, observa-se que existe um vasto campo para o desenvolvimento de novos projetos de pesquisa focando em SDN. Este trabalho serve como um ponta p inicial para
o desenvolvimento de novas pesquisas na rea, seja como ferramenta para estudo
ou como introduo didtica para esse novo paradigma de redes.
8.3
Trabalhos Futuros
O paradigma SDN ainda novo e muitos desafios de pesquisa ainda esto por vir.
Como sugesto para trabalhos futuros so apresentados os seguintes itens:
Difundir esse paradigma em laboratrio e realizar testes em elementos fsicos.
Utilizar as implementaes desenvolvidas no texto em uma rede real.
Expandir futuramente esse modelo para toda a universidade.
Com a implementao deste paradigma na infraestrutura da universidade, os pesquisadores poderiam desenvolver pesquisas de novas tcnicas de rede, com avaliaes em redes reais sem prejuzo no trfego de produo da universidade.
97
Referncias
[1] A.
Al-Shabibi
and
M.
McCauley.
https://openflow.stanford.edu/display/ONL/POX+Wiki.
61, 111
POX-Wiki,
2013.
50, 54, 55, 59, 60,
[2] T. Anderson, L. Peterson, S. Shenker, and J. Turner. Overcoming the Internet

Impasse through Virtualization. IEEE Computer Society Press Los Alamitos, CA,
USA, 38(4):3441, 2005. 14, 16, 94
[3] M. F. Caetano, A.V. Barbosa, P.S. Barreto, and J.L. Bordim. Theoretical Maximum
Throughput of IEEE 802.11g Networkss. IJCSNS International Journal of Computer Science and Network Security, 11(4):136146, 2011. 13
[4] Z. Cai, A. L. Cox, and T. S. Eugene Ng. Maestro: A System for Scalable OpenFlow
Control. Technical report, Rice University, 2010. 32
[5] K. L. Calvert, W. K. Edwards, N. Feamster, R. E. Grinter, Y. Deng, and X. Zhou. Instrumenting Home Networks. Instrumenting home networks. SIGCOMM Comput.
Com-mun. Rev., 1(41):8489, 2011. 37
[6] M. Casado, T. Koponen, R. Ramanathan, and S. Shenker. Virtualizing the Network
Forwarding Plane. Proceedings of the Workshop on Programmable Routers for
Extensible Services of Tomorrow, PRESTO, 8(10):18, 2010. 30
[7] V. G. Cerf and R. E. Kahn. A Protocol for Packet Network Intercommunication.
Institute of Electrical and Electronics Engineers (IEEE), 22(5):113, May 1974. 6
[8] Inc Cisco Systems. IP Telephony: The five nines story. Technical report, Cisco
Systems, Inc, 2002. 13
[9] D. Clark, R. Braden, K. Sollins, J. Wroclawski, and D. Katabi. New Arch: Future
Generation Internet Architecture. M. I. O. T. C. L. F. C. SCIENCE, 235(74):3076,
2004. 4, 11
[10] D. F. Contessa and E. R. Polina. Gerenciamento de Equipamentos Usando o Protocolo SNMP. Technical report, Departamento de Pesquisa e Desenvolvimento CP Eletrnica S.A, 2010. 12
[11] J. Crowcroft, S. Hand, R. Mortier, T. Roscoe, and A. Warfield. Plutarch: An Argument for Network Pluralism. ACM SIGCOMM workshop on Future directions in
network architecture, 1(25):258266, September 2003. 14
98
[12] D.
Erickson.
The
Beacon
Controller,
https://openflow.stanford.edu/display/Beacon/Home/. 32
2012.
[13] C. Dixon et al. The Home Needs an Operating System (and an App Store). In
Proceedings of the Ninth ACM SIGCOMM Workshop on Hot Topics in Networks,
Hotnets, 6(10):118, 2010. 37
[14] D. Guedes et al. Redes Definidas por Software: uma abordagem sistmica para o
desenvolvimento de pesquisas em Redes de Computadores. Minicursos do Simpsio Brasileiro de Redes de Computadores-SBRC 2012, 30(4):160210, 2012.
viii, 24, 26, 27, 29, 37, 38, 95
[15] J. C. Mogul et al. DevoFlow: Cost-Eective Flow Management for High Performance Enterprise Networks. Proceedings of the Ninth ACM SIGCOMM Workshop
on Hot Topics in Networks, Hotnets, 10(1):16, 2010. 27
[16] K. K. Ram et al. sNICh: Ecient Last Hop Networking in the Data Center. Proceedings of the 6th ACM IEEE Symposium on Architectures for Networking and
Communications Systems, ANCS, 10(12):126, 2010. 26
[17] N. Fernandes et al. Virtual Networks: Isolation, Performance, and Trends. Annals
of Telecommunications, 66(5-6):339355, 2010. viii, 14, 15, 94
[18] N. Gude et al. NOX: Towards an Operating System for Networks. SIGCOMM
Comput. Commun., 1(38):105110, 2008. 31, 32
[19] N. McKeown et al. OpenFlow: enabling innovation in campus networks. ACM
SIGCOMM Computer Communication Review, 2(38):6974, March 2008. viii, 14,
18, 19, 40, 44, 47
[20] R. Sherwood et al. Carving Research Slices Out of Your Production Networks
with OpenFlow. SIGCOMM Computer-Communication Networks, 1(40):129130,
2009. viii, 28
[21] R. Sherwood et al. FlowVisor: A Network Virtualization Layer. Technical report,
OPENFLOW-TR, 2009. 28
[22] T. Koponen et al. Onix: A Distributed Control Platform for Large-scale Production
Networks. In Proceedings of the 9th USENIX conference on Operating systems
design and implementation, OSDI, 6(10):114, 2010. 34
[23] N. Feamster. Outsourcing Home Network Security. In Proce-edings of the 2010
ACM SIGCOMM workshop on Home networks, HomeNets, 1(10):3742, 2010. 37
[24] Floodlight. The Floodlight Controller, 2012. http://floodlight.openflowhub.org/.
33
[25] N. Foster, R. Harrison, and M. L. Meola. Frenetic: A High-Level Language for
Openflow Networks. In Proceedings of the Workshop on Programmable Routers
for Extensible Services of Tomorrow, PRESTO, 6(10):16, 2010. 33
99
[26] GENI. Global Environment for Network Innovations, 2012. http://www.geni.net/.

18, 23, 94
[27] IEEE.
Institute of
http://www.ieee.org/. 6
Electrical
and
Electronics
Engineers,
2012.
[28] IETF. Internet Engineering Task Force, 2012. http://www.ietf.org/. 6

[29] ISO. International Organization for Standards, 2012. http://www.iso.org. 6
[30] C. Kamienski, D. Mariz, D. Sadok, and S. Fernandes. Arquiteturas de Rede para
a Prxima Gerao da Internet. Minicursos do Simpsio Brasileiro de Redes de
Computadores-SBRC 2005, 9(3):150, 2005. 12
[31] J. Kurose and K. Ross. Computer Networking, A Top-Down Aproach 5a edio.
Addison-Wesley, 2010. viii, 7, 9, 10, 11
[32] C. Labovitz, A. Ahuja, A. Bose, and F. Jahanian. Delayed Internet Routing Convergence. SIGCOMM: Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, 8(16):175
187, 2000. 13
[33] D. M. F. Mattos. Xenflow: Um Sistema de Processamento de Fluxos Robusto e
Eficiente para Redes Virtuais. Technical report, Deparamento de Eletrnica e de
Computao. UFRJ - Universidade Federal do Rio de Janeiro, 2011. viii, 17, 19,
43
[34] M. McCauley. NOXRepo, 2013. http://www.noxrepo.org. viii, 51
[35] M. Moreira, N. Fernandes, L. Costa, and O. Duarte. Internet do Futuro: Um Novo
Horizonte. Minicursos do Simpsio Brasileiro de Redes de Computadores-SBRC
2009, 8(1):159, 2009. 9, 10, 11, 17, 20
[36] NSF. National Science Foundation, 2012. http://www.nsf.gov/. 6
[37] OASIS. Organization for the Advancement of Structured Information Standards,
2012. http://www.oasis-open.org/. 6
[38] B. Pfa, J. Pettit, T. Koponen, K. Amidon, M. Casado, and S. Shenker. Extending Networking into the Virtualization Layer. In Proceedings of the Eighth ACM
Workshop on Hot Topics in Networks, 8(1):16, 2010. 40
[39] L. Roberts. Living Internet, Lawrence Roberts Manages The ARPANET Program,
2008. http://www.livinginternet.com/i/ii_roberts.htm. 5
[40] C. E. Rothenberg, M. R. Nascimento, M. R. Salvador, and M. F. Magalhes. OpenFlow e redes definidas por software: um novo paradigma de controle e inovao
em redes de pacotes. Cad. CPqD Tecnologia, 7(1):16, July 2010. viii, 22, 25,
42, 46
[41] SNAC. Simple Network Access Control, 2012. http://www.openflow.org/wp/snac/.
34
100
[42] Stanford University. OpenFlow Switch Specification, 1.1.0 edition, February

2011. viii, 19, 20, 23, 27, 42, 60
[43] E. W. Takarabe. Sistema de Controle Distribudo em Redes de Comunicao.
Masters thesis, Escola Politcnica da Universidade de So Paulo, 2009. 10
[44] A. S. Tanenbaum and D. J. Wetherall. Computer Networks. Pearson, Boston,
2011. 5, 7, 9
[45] Trema.
Trema: full-stack OpenFlow framework for Ruby and C, 2012.
http://trema.github.com/trema/. 34
[46] W3C. World Wide Web Consortium, 2012. http://www.w3.org/. 6
[47] Y. Wang, E. Keller, B. Biskeborn, J. van der Merwe, and J. Rexford. Virtual Routers on the Move: Live Router Migration as a Network-Management Primitive.
SIGCOMM Computer Communication Review, 38(4):231242, 2008. 17
101
Apndice A
Descrio dos Elementos do POX
A seguir apresentado a descrio dos componentes bsicos do POX:
Quadro A.1: Descrio dos Componentes nativos do POX.
Componente
py
forwarding.l2_learning
forwarding.l2_pairs
forwarding.l3_learning
forwarding.l2_multi
Descrio
Este componente inicializa um interpretador Python para
a depurao interativa. Este componente executado
automaticamente se a opo nocli estiver desabilitada.
Este componente faz com que os switches OpenFlow funcionem como switches de aprendizagem de camada dois.
No entanto ele instala fluxos extras para conexes com o
mesmo origem/destino, por exemplo, conexes com origens distintas e destinos iguais possuem dois fluxos distintos.
O mesmo que o forwarding.l2_learning, no entanto este
mais simples e mais correto, ele instala regras baseadas
puramente em endereos MAC nao levando a considerao origem e destino.
Este componentes nao chega a ser um roteador, mas
opera em camada trs. Ele uma espcie de switch de
camada trs, operando exatamente como um switch de
camada dois com a diferena entre os endereamentos
de MAC para IP.
Este componente haje como os outros switches de aprendizagem, a diferena est em ambientes com mltiplos
switches. Neste componente quando um switch aprende
um endereo MAC todos os outros das rede tambm
aprendem, para isso este componente utiliza outro componente o openflow.discovery.
102
Quadro A.2: Continuao do Quadro A.1.

Componente
openflow.spanning_tree
web.webcore
messenger
openflow.of_01
openflow.discovery
openflow.debug
openflow.keepalive
Descrio
Este componente usa componentes de descoberta para
construir uma viso da topologia da rede e transformar
esta topologia em uma rvore. Seu objetivo desativar
inundao em portas de switches que no esto nesta rvore. Isso faz com que topologias que tenham laos no
realize transmisses inteis na rede. Este componente
assemelha-se ao efeito produzido pelo o Protocolo Spanning Tree1 , mas realizando isso de uma forma diferente.
Este componente inicia um servidor web dentro do processo do POX. Dessa forma outros componentes podem
interagir com ele fornecendo contedos estticos e dinmicos.
Este um componente que fornece o uma interface para
o POX realizar conexes por meio de mensagens bidirecionais baseadas em JSON2 .
Este o componente que se comunica com os switches
OpenFlow 1.0. Normalmente ele iniciado por padro
quando no especificada a opo noopenflow. As
vezes necessrio chama-lo manualmente quando se
quer modificar suas opes, por exemplo, qual interface
ou porta ele est ligado.
Este componente descobre qual a topologia da rede por
meio de mensagens de controle entre os switches OpenFlow.
Este componente analisa as trocas de mensagens
OpenFlow entre o controlador e os switches da rede.
Assemelha-se as anlises do tcpdump ou do WireShark
(discutido melhor depois) sendo mais sinttica.
Este componente faz com que o POX envie solicitaes
peridicas de eco para switches conectados. Alguns switches, aps um longo periodo de silncio, podem assumir
que a ligao est inativa ou que houve uma perda de
conectividade com o controlador e sendo assim este ir
se desligar. Dessa forma este componente evita este problema.
Spanning Tree Protocol (STP) um protocolo para equipamentos de rede que permite resolver
problemas de laos em redes comutadas cuja topologia introduza anis nas ligaes.
2
JavaScript Object Notation, um formato leve para intercmbio de dados computacionais que
pode ou no utilizar-se de JavaScript. http://www.json.org/.
103

Componente
misc.pong
misc.arp_responder
misc.packet_dump
misc.dns_spy
misc.of_tutorial
misc.mac_blocker
log
log.color
samples.pretty_log
tk
Descrio
Este componente um exemplo simples de como se trabalhar com o monitoramento e o envio de pacotes ICMP.
Sua execuo faz com que todos os pings realizados tenha uma resposta pong.
O mesmo que o anterior com a diferena que responde
requisies ARP a partir de uma lista de entradas estticas.
Um simples componente que exibe informaes de pacotes. como executar um tcpdump em um host.
Este componente monitora as respostas DNS e guarda
seus resultados.
Este componente um tutorial simples que mostra como
transformar uma hub em um switch de aprendizagem de
camada dois. Este o tutorial utilizado no OpenFlow Tutorial3 .
Este componente feito para ser usado ao lado de outros
componentes de encaminhamento. Aparecer uma interface grfica que permite bloquear endereos MAC. Este
um exemplo que demonstra o uso de eventos de bloqueio
e como criar componentes com interface grfica.
O POX utiliza-se de mensagens de log do Python que por
sua vez podem ser configuradas nas das linhas de comando, por exemplo, possvel configurar logs que incluam data e hora.
Este componente faz com que o log seja exibido com
cores de diferenciadas no terminal, muito interessante
quando se quer fazer depuraes.
Este componente personaliza as sadas do log para uma
melhor visualizao.
Este componente utilizado para ajudar na construo
de interfaces grficas baseadas no POX.
Os Quadros A.4, A.5 e A.6 mostram uma anlise de algumas das principais classes
da biblioteca pox.lib.packet, maiores detalhes sobre as outras classes podem ser
encontradas nas classes especificas no diretrio pox/lib/packet.
OpenFlow Tutorial http://www.openflow.org/wk/index.php/OpenFlow_Tutorial
104
Quadro A.4: Anlise da classe Ethernet do POX.

Atributos
dst
src
type(int)
effective_ethertype(int)
Constantes
IP_TYPE
ARP_TYPE
RARP_TYPE
VLAN_TYPE
LLDP_TYPE
JUMBO_TYPE
QINQ_TYPE
Descrio
Endereo MAC de destino
Endereo MAC da fonte
Define o tamanho do campo do pacote ethernet.
Delimita o tamanho do cabealho da VLAN
Descrio
Define um pacote do tipo IP (Exemplo no cdigo
da pagina 56)
Define um pacote do tipo ARP
Define um pacote do tipo RARP
Define um pacote do tipo VLAN
Define um pacote do tipo LLDP
Define um pacote do tipo JUMBO
Define um pacote do tipo QINQ
Quadro A.5: Anlise da classe IP do POX.

Atributos
dstip
srcip
tos(int)
id(int)
flags(int)
ttl(int)
protocol(int)
csum(int)
Constantes
ICMP_PROTOCOL
TCP_PROTOCOL
UDP_PROTOCOL
DF_FLAG
MF_FLAG
Descrio
Endereo IP de destino
Endereo IP da fonte
O histrico campo de tipo de servio TOS(8 bits).
Campo de identificao
Campos de flag
Tempo de vida do pacote
Nmero do protocolo IP
Checksum do pacote IP
Descrio
Define o protocolo do pacote como ICMP
Define o protocolo do pacote como TCP
Define o protocolo do pacote como UDP
Define o bit DF(dont fragment)
Define o bit MF(more fragments)
105
Quadro A.6: Anlise da classe TCP do POX.

Atributos
dstport
srcport
seq(int)
ack(int)
off(int)
Descrio
Define a porta TCP de destino
Define a porta TCP de sada da fonte
Nmero de sequencia
nmero do ACK
Indica a posio qual pertence o fragmento
atual (oset)
flags(int)
flags do pacote TCP
csum(int)
Checksum do pacote TCP
options
Lista de opes da classe tcp_opt
win(int)
Tamanho da janela TCP
urg(int)
Flag urg de pacote TCP urgente
FIN(bool)
Flag FIN do pacote
SYN(bool)
Flag SYN do pacote
RST(bool)
Flag RST do pacote
ACK(bool)
Flag ACK do pacote
Constantes Descrio
FIN_flag
Define os bits correspondente a flag FIN
SYN_flag
Define os bits correspondente a flag SYN
Os Quadros A.7 e A.8 mostram os argumentos de construo da classe Timer. O

Quadro A.9 mostra seus mtodos.
Quadro A.7: Argumentos de construo da classe Timer.
Atributos
Descrio
timeToWake
a quantidade de tempo de espera (em segundos) para chamar a funo em callback isso se
absoluteTime = False ou o tempo especfico
para chamar callback isso se absoluteTime =
True
A funo que ser chamada
Quando False o timeToWake define o tempo de
espera do callback, quando True timeToWake
um tempo especfico no futuro. No possvel
que este valor seja True quando o Timer recorrente
Quando False o callback dispara uma nica s
vez, se True o callback recorrente pelo tempo
definido em timeToWake
callback
absoluteTime
recurring
106

Atributos
args, kw
scheduler
started
selfStoppable
Descrio
Esses so os argumentos passados para a funo
do callback
Qual ser o agendador de tarefas utilizado
(scheduler()). Se for None ser executado o
scheduler padro
Quando True, o Timer executado automaticamente.
Quando True, se o retorno de um Timer recorrente for False ele cancela a thread
Quadro A.9: Mtodos da classe Timer.

Mtodos
cancel()
run()
Descrio
Para a thread, no chama ele novamente
Executa a thread
A seguir so apresentados os diversos eventos para o controle de mensagens

OpenFlow:
Quadro A.10: Eventos fornecidos do mdulo OpenFlow no POX.
Evento
ConnectionUp
ConnectionDown
PortStatus
FlowRemoved
PacketIn
Descrio
Evento gerado quando um comutador OpenFlow
tm uma conexo estabelecida com o controlador
Evento gerado quando um comutador OpenFlow
perde uma conexo com o controlador
Evento gerado quando h alguma mudana no
status das portas dos comutadores OpenFlow
Evento gerado quando algum comutador remove
alguma entrada em sua tabela de fluxos
Evento gerado quando algum comutador recebe
um pacote que no pertena a nenhum fluxo em
sua tabela de fluxos. O pacote enviado ao controlador.
107

Evento
ErrorIn
Descrio
Evento gerado quando um comutador envia uma
mensagem de erro OpenFlow ao controlador.
possvel utilizar o mtodo asString para ver a representao do erro OpenFlow
BarrierIn
Evento gerado em resposta a uma mensagem
OpenFlow Barrier
RawStatsReply
Mostra eventos estatsticos de forma geral. No
muito interessante pois mostram todas as mensagens OpenFlow
StatsReply
a superclasse para todas as outras classes de
eventos estatsticos. Os outros eventos estatsticos mostram grupos de mensagens OpenFlow
separadamente. Eventos estatsticos so basicamente utilizados para depurao e gerenciamento da rede.
SwitchDescReceived
Classe de evento que herda StatsReply. Mostra
os status do comutador
FlowStatsReceived
os status dos fluxos do comutador
AggregateFlowStatsReceived Classe de evento que herda StatsReply. Mostra
alteraes de fluxo do comutador
TableStatsReceived
o status da tabela de fluxo do comutador
PortStatsReceived
o status das portas do comutador
QueueStatsReceived
o status das filas do comutador
Os Quadros A.12 e A.13 mostram os atributos da classe of.ofp_packet_out:

Quadro A.12: Definio dos atributos da classe of.ofp_packet_out do POX.
Atributo
buffer_id
Tipo
int/None
Padro
None
in_port
int
OFPP_NONE
108
Descrio
ID do buer no qual o pacote armazenado.
A porta no qual o pacote chegou

Atributo
actions
Tipo
list of
ofp_action
Padro
[]
data
bytes/ethernet/ (nada)
ofp_packet_in
Descrio
Lista de aes que o comutador deve
realizar. Essas aes so outros tipos
de mensagens OpenFlow
Os dados a ser enviado, ou nenhum
se o pacote estiver no buer do
comutador (buffer_id diferente de
None)
Os Quadros A.14 e A.15 mostram os atributos da classe of.ofp_flow_mod:

Quadro A.14: Definio dos atributos da classe of.ofp_flow_mod do POX.
Atributo
cookie
Tipo
int
command
int
idle_timeout
int
hard_timeout
int
priority
int
buffer_id
out_port
int
int
Padro
0
Descrio
ID desta regra (entrada da tabela de fluxo)
OFPFC_ADD
Qual o comando OFPFC_XXXX.
Pode-se usar os seguinte valores:
ADD (adicionar uma
regra),MODIFY (modificar uma
regra),MODIFY_STRICT
(modificar regras com valores
universais),DELETE
(eliminar
uma regra) e DELETE_STRICT
(eliminar regras com valores
universais)
OFP_FLOW_
A regra ir expirar por esse pePERMANENT
rodo (em segundos) se no for
usada. O valor padro significa
que a regra no ir expirar
OFP_FLOW_
A regra ir expirar por esse pePERMANENT
rodo (em segundos). O valor
padro significa que a regra no
ir expirar
OFP_DEFAULT_ A prioridade da regra. Nmeros
PRIORITY
mais altos ter prioridades maiores
None
O buer do fluxo de dados
OFPP_NONE
Este campo utilizado para os
comandos de eliminao de regras
109

Atributo
flags
Tipo
int
Padro
0
actions
list of
ofp_action
ofp_match
[]
match
(nada)
Descrio
Algumas flags de controle.
OFPFF_SEND_FLOW_REM
(envia mensagens de fluxo
removido
ao
controlador
quando uma regra expira),
OFPFF_CHECK_OVERLAP
(verifica se no h sobreposio
de entrada na tabela, se existir envia uma mensagem ao
controlador) e OFPFF_EMERG
(mensagem de emergncia se
acontecer algo ao comutador)
As aes que so tomadas pelo
fluxo
A estrutura da regra, define o
fluxo
O Quadro A.16 a seguir mostra os atributos da classe of.ofp_match:

Quadro A.16: Definio dos atributos da classe of.ofp_match do POX.
Atributo
in_port
dl_src
dl_dst
dl_vlan
dl_vlan_pcp
dl_type
nw_tos
nw_proto
nw_src
nw_dst
tp_src
tp_dst
Descrio
Muda o nmero da porta que o pacote chegou
MAC de origem
MAC de destino
ID da VLAN
Prioridade da VLAN
Tamanho do pacote Ethernet
Define os bits DF e MF
Qual o tipo de protocolo da camada 3
IP de origem
IP de destino
TCP/UDP de origem
TCP/UDP de destino
O Quadro A.17 a seguir mostra as classes de ao do POX e suas descries:

110
Quadro A.17: Definio de algumas das classes ofp_action do POX.

Classe
of.ofp_action_output
ofp_action_enqueue
ofp_action_vlan_vid
ofp_action_vlan_pcp
ofp_action_dl_addr
ofp_action_nw_addr
ofp_action_nw_tos
ofp_action_tp_port
Descrio
Encaminha pacotes para uma porta fsica ou
virtual. Valores possveis: OFPP_IN_PORT (envia o pacote de volta pela porta de origem),
OFPP_TABLE (executa aes especificas no fluxo,
s se aplica a mensagens de ofp_packet_out),
OFPP_NORMAL (processo normal de comutao,
para fluxo de produo), OFPP_FLOOD (para todas as portas, exceto a de entrada e portas com
floods desativados), OFPP_ALL (para todas as portas, exceto a de entrada), OFPP_CONTROLLER
(para o controlador), OFPP_LOCAL (para suas portas locais) ou OFPP_NONE (para nenhum lugar,
descarta o pacote)
Encaminha o pacote para uma fila designada
no comutador para implementar QoS rudimentar. Note que o comportamento de filas no de
responsabilidade do OpenFlow, esta responsabilidade somente do comutador
Se o pacote no tiver um cabealho VLAN, essa
ao adiciona uma e define seu ID com o valor
especificado e sua prioridade para 0. Caso j tenha um cabealho VLAN ele apenas modifica sua
ID
O mesmo que o anterior, s que se j tiver um cabealho VLAN ele apenas modifica sua prioridade
Usado para definir a origem ou o destino endereo MAC
Usado para definir a origem ou o destino endereo IP
Defina o campo TOS de um pacote IP
Usado para definir a porta TCP/UDP de origem ou
destino
Para maiores informaes procure a POX Wiki [1].
111
Apndice B
Cdigos das Implementaes
Desenvolvidas
B.1
Cdigo do Terceiro Cenrio
A seguir apresentado o cdigo para a criao do terceiro cenrio de testes com

comentrios:
1
2
3
4
5
from
from
from
from
from
mininet . net import M i n i n e t

mininet . node import C o n t r o l l e r , OVSKernelSwitch , RemoteController
mininet . c l i import C L I
mininet . l o g import setLogLevel , i n f o
mininet . u t i l import c r e a t e L i n k
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
def c r e a t e S t a t i c R o u t e r N e t w o r k ( ) :
i n f o ( Criando a Rede do Cenario 3 ( Exemplo ) \ n )
# C r i a uma rede v a z i a com o c o n t r o l a d o r remoto
net = M i n i n e t ( c o n t r o l l e r=RemoteController , s w i t c h=OVSKernelSwitch )
#a d i c i o n a um c o n t r o l a d o r
net . a d d C o n t r o l l e r ( c0 )
# C r i a os nos da rede .
h0 = net . addHost ( h0 )
s0 = net . addSwitch ( s0 )
# C r i a os l i n k s da rede .
h0int , s 0 i n t = c r e a t e L i n k ( h0 , s0 )
s 0 p i n t , s 1 p i n t = c r e a t e L i n k ( s0 , s1 )
112
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# Configurando os i p s e as i n t e r f a c e s
s0 . s e t I P ( s 0 i n t , 1 0 . 0 . 1 . 1 , 24)
h0 . s e t I P ( h0int , 1 0 . 0 . 1 . 2 , 24)
h1 . s e t I P ( h1int , 1 0 . 0 . 1 . 3 , 24)
s1 . s e t I P ( s 1 i n t , 1 0 . 0 . 2 . 1 , 24)
h2 . s e t I P ( h2int , 1 0 . 0 . 2 . 2 , 24)
h3 . s e t I P ( h3int , 1 0 . 0 . 2 . 3 , 24)
s2 . s e t I P ( s 2 i n t , 1 0 . 0 . 3 . 1 , 24)
h4 . s e t I P ( h4int , 1 0 . 0 . 3 . 2 , 24)
h5 . s e t I P ( h5int , 1 0 . 0 . 3 . 3 , 24)
s0 . s e t I P ( s 0 p i n t , 1 0 . 0 . 1 . 2 5 5 , 24)
s1 . s e t I P ( s 1 p i n t , 1 0 . 0 . 2 . 2 5 5 , 24)
s2 . s e t I P ( s 2 p i n t , 1 0 . 0 . 3 . 2 5 5 , 24)
i n f o ( Estado da rede : \ n )
f o r node i n s0 , h0 , h1 , s1 , h2 , h3 , s2 , h4 , h5 :
i n f o ( s t r ( node ) + \ n )
# I n i c i a o C L I do mininet
net . s t a r t ( )
C L I ( net )
net . stop ( )
53
54
55
56
i f __name__ == __main__ :
createStaticRouterNetwork ( )
codigos/cenario3.py
Para executar este cdigo, basta criar o arquivo acima na pasta mininet/custom
com o nome cenario3.py e compilar o cdigo Python dentro da pasta na VM Mininet:
$ cd mininet/custom
sudo python -O cenario3.py
Aps isso ser criada a rede do terceiro cenrio de testes.
B.2
Cdigo do HUB
A seguir apresentado o cdigo do componente HUB com comentrios.

1
2
3
4

from pox . l i b . u t i l import d p i d T o S t r
from pox . l i b . revent import
import pox . openflow . l i b o p e n f l o w _ 0 1 as o f
5
6
l o g = core . getLogger ( )
7
8
c l a s s Hub ( o b j e c t ) :
113
9
10
11
12
13
def _ _ i n i t _ _ ( s e l f , connection ) : #i n i c i a d o r da c l a s s e
# a connection e n e c e s s a r i a para que se possa e n v i a r as mensagens
openflow
s e l f . connection = connection
# f a z com que se possa o u v i r o evento P a c k e t I n
connection . a d d L i s t e n e r s ( s e l f )
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
def a c t _ l i k e _ h u b ( s e l f , p a c k e t _ i n ) :
"""
Implementa o HUB envia o pacote para todas suas p o r t a s menos a de
entrada
"""
msg = o f . o f p _ p a c k e t _ o u t ( )# i n s t r u i em qual p o r t a o pacote deve s a i r
msg . i n _ p o r t = p a c k e t _ i n . i n _ p o r t# a t r i b u i n d o o parametro i n _ p o r t da msg
#v e r i f i c a se o pacote esta no b u f f e r do s w i t c h
i f p a c k e t _ i n . b u f f e r _ i d != 1 and p a c k e t _ i n . b u f f e r _ i d i s not None :
# se o pacote e s t i v e r no b u f f e r do s w i t c h u t i l i z e o pacote do
buffer
msg . b u f f e r _ i d = p a c k e t _ i n . b u f f e r _ i d
else :
# o pacote nao esta no b u f f e r do s w i t c h
i f p a c k e t _ i n . data i s None :#v e r i f i c a se o pacote que chegou a
c o n t r o l a d o r esta v a z i o
# o pacote esta vazio , nada a f a z e r
return
# o pacote que chegou ao c o n t r o l a d o r nao esta vazio , e nao esta no
b u f f e r do s w i t c h
# entao se a t r i b u i o dado do pacote que chegou ao c o n t r o l a d o r na
msg
msg . data = p a c k e t _ i n . data
l o g . debug ( " Enviando para todas as p o r t a s " )
# A d i c i o n a a acao na msg openflow que sera mandada ao s w i t c h
a c t i o n = o f . o f p _ a c t i o n _ o u t p u t ( p o r t = o f . OFPP_FLOOD )
msg . a c t i o n s . append ( a c t i o n )
# envia a mendagem para o s w i t c h
s e l f . connection . send (msg)
39
40
41
42
43
44
45
46
47
48
49
50
"""
E s c u l t a as mensagens P a c k e t I n da rede
"""
l o g . debug ( " Chegou um pacote no s w i t c h %s " , d p i d T o S t r ( event . dpid ) )
packet_eth = event . parsed # Faz a a n a l i s e dos dados do pacote do evento
#e n e c e s s a r i o f a z e r o event . parsed para que se possa t e r acesso aos
#cabecalhos do pacote
i f not packet_eth . parsed :
l o g . warning ( " Pacote f o i ignorado p o i s nao ha cabecalhos " )
return
51
52
53
p a c k e t _ i n = event . ofp # A mensagem openflow do evento

s e l f . act_like_hub ( packet_in )
54
55
def launch ( ) :#i n i c i a se o componente va para a l i n h a 63
56
57
def s t a r t _ s w i t c h ( event ) : #evento o b t i d o metodo i n i c i a d o
114
#observe que a c l a s s e hub recebe um parametro , que e a conexao do

switch
#esse parametro e n e c e s s a r i o para que se mantenha a conexao com o
switch
#e possa e n v i a r mensagens openflow para e l e
Hub ( event . connection )# enviamos a conexao do evento para a c l a s s e
58
59
60
61
62
63
64
65
# quando ouvimos o evento ConnectionUp executamos o metodo s t a r t _ s w i t c h

# para i s s o , temos que r e g i s t r a r um o u v i n t e no nucleo do pox :
core . openflow . addListenerByName ( " ConnectionUp " , s t a r t _ s w i t c h )#
r e g i s t r a m o s o o u v i n t e para o b t e r o evento
codigos/hub.py
B.3
Cdigo do SWITCH
A seguir apresentado o cdigo do componente SWITCH com comentrios.

1
2
3
4

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
"""
e c r i a d a uma d i c i o n a r i o ( l i s t a ) g l o b a l para que o componente
i d e n t i f i q u e os pares endereco MAC p o r t a de s w i t c h
note que essa t a b e l a e g l o b a l da rede , i s s o nao f a r i a s e n t i d o se
tivessemos mais que um s w i t c h
"""
mac_to_port = {}
c l a s s Switch ( o b j e c t ) :
openflow
20
21
22
23
24
25
26
def a c t _ l i k e _ s w i t c h ( s e l f , packet_in , packet ) :

"""
Implementa o Switch de auto aprendizagem aprende os caminhos de
todos os seus nos
i n s t a l a n d o as entradas na t a b e l a de f l u x o do s w i t c h ( desempenho muito
melhor que o HUB) .
"""
mac_to_port [ s t r ( packet . s r c ) ] = p a c k e t _ i n . i n _ p o r t
27
28
29
30
31
###Enviando os pacotes a t r a v e s da i n s t a l a c a o de r e g r a s
i f s t r ( packet . d s t ) i n mac_to_port :
p o r t = mac_to_port [ s t r ( packet . d s t ) ]
l o g . debug ( " Enviando pacote para a p o r t a %d " %( p o r t ) )
115
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
msg = o f . ofp_flow_mod ( )
#c r i a n d o o f l u x o , esse f l u x o determina apenas o endereco MAC de
destino
msg . match = o f . ofp_match ( d l _ d s t = packet . d s t )
l o g . debug ( " i n s t a l a n d o f l u x o de %s.% i " % ( packet . dst , p o r t ) )
"""
a l t e r n a t i v a m e n t e podemos f a z e r assim :
msg . match = o f . ofp_match . from_packet ( packet )
l o g . debug ( " i n s t a l a n d o f l u x o de %s.% i para %s.% i " % ( packet . src ,
p a c k e t _ i n . i n _ p o r t , packet . dst , p o r t ) )
porem f l u x o f i c a r a mais e s p e c i f i c o , i n s t a l a r a um f l u x o
da f o n t e MAC x para o d e s t i n o MAC y
"""
msg . i d l e _ t i m e o u t = 10
msg . hard_timeout = 30
else :
i f p a c k e t _ i n . data i s None :
return
msg . a c t i o n s . append ( o f . o f p _ a c t i o n _ o u t p u t ( p o r t = p o r t ) )
else :
p o r t = o f . OFPP_FLOOD
56
57
58
59
60
61
62
63
64
65
66
67
68
69
msg = o f . o f p _ p a c k e t _ o u t ( )
msg . i n _ p o r t = p a c k e t _ i n . i n _ p o r t
else :
return
action = of . ofp_action_output ( port = port )
# envia a mendagem para o s w i t c h
70
71
72
73
74
75
76
77
78
79
"""
"""
packet_eth = event . parsed
return
80
81
82
83

s e l f . a c t _ l i k e _ s w i t c h ( packet_in , packet_eth )#agora enviamos os
cabecalhos dos pacotes
#para que o s w i t c h possa gravar seus enderecos em uma t a b e l a
84
116
85
def launch ( ) :
86
87
88
89
def s t a r t _ s w i t c h ( event ) :
Switch ( event . connection )# enviamos a conexao do evento para a
classe
core . openflow . addListenerByName ( " ConnectionUp " , s t a r t _ s w i t c h )
codigos/switch.py
B.4
Cdigo do SWITCHES
A seguir apresentado o cdigo do componente SWITCHES com comentrios.

1
2
3
4

5
6
7
8
9
10
11
12
13
14
15
"""
dessa vez as chaves do d i c i o n a r i o sao t u p l a s de endereco MAC e ID do s w i t c h
para que cada s w i t c h tenha sua p r o p r i a regra de encaminhamento
"""
mac_dpid_to_port = {}
c l a s s Switches ( o b j e c t ) :
def _ _ i n i t _ _ ( s e l f , connection ) :
16
17
18
19
20
21
22
23
24
25
26
27
28
29
def a c t _ l i k e _ s w i t c h e s ( s e l f , packet_in , packet , dpid ) :

"""
Implementa v a r i o s Switches de auto aprendizagem e n e c e s s a r i o que se
tenha
o i d de cada s w i t c h para que possa s e r i n s t a l a d o r e g r a s e s p e c i f i c a s do
switch .
"""
mac_dpid_to_port [ ( s t r ( packet . s r c ) , d p i d T o S t r ( dpid ) ) ] = p a c k e t _ i n . i n _ p o r t
#a chave e uma t u p l a
i f ( s t r ( packet . d s t ) , d p i d T o S t r ( dpid ) ) i n mac_dpid_to_port :
p o r t = mac_dpid_to_port [ ( s t r ( packet . d s t ) , d p i d T o S t r ( dpid ) ) ]
#c r i a n d o o f l u x o , esse f l u x o determina apenas o endereco MAC de
destino
msg . match = o f . ofp_match ( d l _ d s t = packet . d s t )
l o g . debug ( " i n s t a l a n d o f l u x o de %s.% i no s w i t c h %s " % ( packet . dst ,
port , d p i d T o S t r ( dpid ) ) )
30
31
32
33
34
117
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
else :
return
else :
else :
return
# envia a mendagem para o s w i t c h chamou o evento
57
58
59
60
61
62
63
64
65
66
"""
"""
return
67
68
69
70

dpid = event . dpid#passa o i d do s w i t c h que gerou o evento
s e l f . a c t _ l i k e _ s w i t c h e s ( packet_in , packet_eth , dpid )#agora e enviado o
i d de cada s w i t c h
71
72
def launch ( ) :
73
74
75
76
Switches ( event . connection )# enviamos a conexao do evento para a
classe
codigos/switches.py
B.5
Cdigo do FIREWALL
A seguir apresentado o cdigo do componente FIREWALL com comentrios.

1
118
2
3
4
5

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Firewall ( object ) :

openflow
"""
note que agora a v a r i a v e l mac_to_port nao e mais g l o b a l , pertence a
classe
p o r t a n t o quando cada s w i t c h se conecta ao c o n t r o l a d o r sao c r i a d a s
instancias diferentes
que por sua vez contem mac_to_port d i f e r e n t e s nao necessitando do
dpid para d i f e r e n c i a r
"""
s e l f . mac_to_port = {}
s e l f . i n s t a l l _ f i r e w a l l _ r u l e s ( )#i n s t a l a as r e g r a s de f i r e w a l l ao se
conectar um s w i t c h
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
def i n s t a l l _ f i r e w a l l _ r u l e s ( s e l f ) :
"""
Assim que os s w i t c h e s se conectam ao c o n t r o l a d o r as r e g r a s de f i r e w a l l
aqui d e f i n i d a s j a sao i n s t a l a d a s nos switches , de maneira que o pacote
que
se enquadre nessas r e g r a s j a t e r a seu d e s t i n o d e f i n i d o , s e j a e l e o
descarte ,
enviado para uma p o r t a ou se enviado ao c o n t r o l a d o r ( P a c k e t I n ) .
Neste u l t i m o caso o _ h a n d l e _ P a c k e t I n recebera este pacote
que devera s e r t r a t a d o l a .
E x i s t e v a r i a s maneiras de se implementar um f i r e w a l l , esta e so uma
maneira
"""
###P r i m e i r a Regra
l o g . debug ( " P r i m e i r a regra i n s t a l a d a no Switch %s , pacotes com d e s t i n o a
p o r t a tcp 80 enviados para o c o n t r o l a d o r "
%( d p i d T o S t r ( s e l f . connection . dpid ) ) )
msg = o f . ofp_flow_mod ( )#c r i a a mensagem para s e r enviada ao s w i t c h
#e c r i a d a o f l u x o que desejamos que s e j a pego no f i r e w a l l
msg . match = o f . ofp_match ( d l _ t y p e = pkt . e t h e r n e t . IP_TYPE , nw_proto = pkt
. ipv4 . TCP_PROTOCOL , t p _ d s t = 80)
#tem que s e r um pacote e t h e r n e t que tenha um pacote I P dentro que tenha
#um pacote TCP dentro com d e s t i n o na p o r t a 80
msg . a c t i o n s . append ( o f . o f p _ a c t i o n _ o u t p u t ( p o r t = o f . OFPP_CONTROLLER ) )#
acao e n v i a r ao c o n t r o l a d o r
###
###Segunda Regra
l o g . debug ( " Segunda regra i n s t a l a d a no Switch %s , pacotes com d e s t i n o ao
I P 1 0 . 0 . 0 . 2 enviados para o c o n t r o l a d o r "
119
46
47
48
49
50
51
52
53
%( d p i d T o S t r ( s e l f . connection . dpid ) ) )
msg . match = o f . ofp_match ( d l _ t y p e = pkt . e t h e r n e t . IP_TYPE , nw_dst = "
10.0.0.2 " )
#esse f l u x o e mais simples , um pacote e t h e r n e t que tenha um pacote I P
dentro com
#d e s t i n o ao endereco I P 1 0 . 0 . 0 . 2
msg . a c t i o n s . append ( o f . o f p _ a c t i o n _ o u t p u t ( p o r t = o f . OFPP_CONTROLLER ) )
###
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
def a c t _ l i k e _ s w i t c h ( s e l f , packet_in , packet ) :

"""
age como o switch , com d i f e r e n c a no match v e j a abaixo
"""
s e l f . mac_to_port [ s t r ( packet . s r c ) ] = p a c k e t _ i n . i n _ p o r t
i f s t r ( packet . d s t ) i n s e l f . mac_to_port :
p o r t = s e l f . mac_to_port [ s t r ( packet . d s t ) ]
#msg . match = o f . ofp_match ( d l _ d s t = packet . d s t )
"""
o f l u x o acima e muito simples , e p r e c i s o s e r mais e s p e c i f i c o
nessa regra
p o i s imagine o caso em que h1 envia pacotes para h2 todos com tcp
p o r t 80
logo depois e l e envia um pacote com tcp p o r t 1234.
o s w i t c h pensara que e o mesmo f l u x o e passara pela mesma p o r t a
caso faca da maneira abaixo o s w i t c h percebera que o f l u x o e
diferente
p o i s se d i f e r e a p o r t tcp e e n v i a r a o pacote para o c o t r o l a d o r
a n a l i s a r ( PacketIn )
"""
msg . match = o f . ofp_match . from_packet ( packet )
l o g . debug ( " i n s t a l a n d o f l u x o de %s.% i do type %d " % ( packet . dst ,
port , packet . type ) )
else :
return
else :
else :
return
120

95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
"""
"""
return
"""
Como todos os f l u x o s do f i r e w a l l tem o d e s t i n o ao c o n t r o l a d o r e gerado
uma msg
do t i p o P a c k e t I n que deve s e r t r a t a d a aqui , logo os pacotes que tem os
f l u x o s que o f i r e w a l l enviou deve s e r i d e n t i f i c a d o s e descartados
"""
#v e r i f i c a se o pack eth tem um pack i p
i f packet_eth . type == pkt . e t h e r n e t . IP_TYPE :
#pega o payload dele e a t r i b u i ao pack i p
p a c k e t _ i p = packet_eth . payload
#v e r i f i c a a condicao do f i r e w a l l
i f p a c k e t _ i p . d s t i p == " 1 0 . 0 . 0 . 2 " :
l o g . warning ( " Pacote para o I P 1 0 . 0 . 0 . 2 e descartado " )
return
#v e r i f i c a se o pack i p tem um pack tcp
i f p a c k e t _ i p . p r o t o c o l == pkt . ipv4 . TCP_PROTOCOL :
#pega o payload dele e a t r i b u i ao pack tcp
packet_tcp = p a c k e t _ i p . payload
#v e r i f i c a a condicao do f i r e w a l l
i f packet_tcp . d s t p o r t == 80:
l o g . warning ( " Pacote para a p o r t a tcp 80 e descartado " )
return
#continua a execucao normal
p a c k e t _ i n = event . ofp
s e l f . a c t _ l i k e _ s w i t c h ( packet_in , packet_eth )
133
134
def launch ( ) :
135
136
137
138
F i r e w a l l ( event . connection )# enviamos a conexao do evento para a
classe
codigos/firewall.py
B.6
Cdigo do ROUTER
A seguir apresentado o cdigo do componente ROUTER com maiores detalhes

nos comentrios.
121
1
2
3
4
5
6
7
8
9
10
11

import pox
from pox . l i b . packet . e t h e r n e t import e t h e r n e t
from pox . l i b . packet . ipv4 import ipv4 , IP_ANY
from pox . l i b . packet . arp import arp
import time
12
13
14
# O tempo maximo parado dos f l u x o s

FLOW_IDLE_TIMEOUT = 10
15
16
17
# Tempo maximo das entradas ARP

ARP_TIMEOUT = 60 2
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
c l a s s Router ( o b j e c t ) :
"""
e c r i a d a uma t a b e l a ARP semelhante as a n t e r i o r e s , dessa vez esta t a b e l a
e I P para MAC e p o r t a . Tem como chave o endereco I P e como v a l o r e s a
porta
o MAC e o timeout .
Exemplo de uma entrada :
{ IPAddr ( 1 0 . 0 . 1 . 2 ) : ( 1 , EthAddr ( 9 6 : 9 5 : 8 2 : 9 e : 7 2 : 3 e ) ,
1358653720.522618)}
Logo para a p o r t a de chegada basta pegar o p r i m e i r o v a l o r da t u p l a
[0]
para o endereco MAC basta pegar o segundo v a l o r da t u p l a [ 1 ]
para o tempo basta pegar o t e r c e i r o v a l o r da t u p l a [ 2 ]
"""
s e l f . a r p _ t a b l e = {}
"""
e uma t a b e l a que guarda todos os i p s que passam pelo comutador , t a n t o
de d e s t i n o
quanto de f o n t e . Essa t a b e l a serve para que i p s que nao existem na rede
nao fiquem sendo
inundados em um l a c o sem fim quando se quer usar o p r o t o c o l o ARP .
sua chave e o I P e seus v a l o r e s sao um bool e um time .
"""
s e l f . t a b l e _ i p = {}
43
44
45
46
47
def arp_responder ( s e l f , packet_in , packet , dpid ) :

"""
Este metodo responde as r e q u i s i c o e s ARP , quando o I P nao e encontrado
na t a b e l a
122
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
e l e inunda todas as p o r t a s do comutador procurando . E muito

semelhante ao s w i t c h
so que dessa vez e l e procura I P s e nao MACs
"""
packet_arp = packet . next#pega o datagrama do quadro
#mostra se e l e e uma r e q u i s i c a o ARP ou uma r e s p o s t a ARP
l o g . debug ( "%s %i ARP %s %s => %s " , d p i d T o S t r ( dpid ) , p a c k e t _ i n . i n _ p o r t
,
{arp . REQUEST : " request " , arp . REPLY : " r e p l y " } . get ( packet_arp .
opcode ,
op:% i % ( packet_arp . opcode , ) ) , s t r ( packet_arp . p r o t o s r c ) ,
s t r ( packet_arp . p r o t o d s t ) )
#Faz algumas c o n f e r e n c i a b a s i c a s para ver se datagrama ARP esta
completo :
i f packet_arp . p r ot ot y pe == arp . PROTO_TYPE_IP :#p r i m e i r a
i f packet_arp . hwtype == arp . HW_TYPE_ETHERNET :#segunda
#t e r c e i r a , v e r i f i c a se o I P da f o n t e nao e 0 . 0 . 0 . 0
i f packet_arp . p r o t o s r c != IP_ANY :
# aprende a p o r t a /MAC a t u a l i z a n d o o time
l o g . debug ( "%s %i aprendendo %s " , d p i d T o S t r ( dpid ) ,
packet_in . in_port ,
packet_arp . p r o t o s r c )
s e l f . a r p _ t a b l e [ packet_arp . p r o t o s r c ] = ( p a c k e t _ i n . i n _ p o r t ,
packet . src ,
time . time ( ) +
ARP_TIMEOUT )
#v e r i f i c a se o pacote arp e request para f a z e r o r e p l y
i f packet_arp . opcode == arp . REQUEST :
#v e r i f i c a se o i p de d e s t i n o e conhecido
i f packet_arp . p r o t o d s t i n s e l f . a r p _ t a b l e :
#v e r i f i c a se o tempo do ARP nao e x p i r o u j a
i f not time . time ( ) > s e l f . a r p _ t a b l e [ packet_arp .
protodst ] [ 2 ] :
#c r i a um pacote arp de r e s p o s t a
r e p l y = arp ( )
r e p l y . hwtype = packet_arp . hwtype
r e p l y . pr o to t yp e = packet_arp . p r ot o ty p e
r e p l y . hwlen = packet_arp . hwlen
r e p l y . p r o t o l e n = packet_arp . p r o t o l e n
r e p l y . opcode = arp . REPLY
r e p l y . hwdst = packet_arp . hwsrc
r e p l y . p r o t o d s t = packet_arp . p r o t o s r c#d e s t i n o=
f o n t e do request
r e p l y . p r o t o s r c = packet_arp . p r o t o d s t#f o n t e=
d e s t i n o do request
#busca na t a b e l a o MAC
r e p l y . hwsrc = s e l f . a r p _ t a b l e [ packet_arp .
protodst ] [ 1 ]
#empacota o pacote em um quadro
e t h e r = e t h e r n e t ( type=packet . type , s r c=r e p l y .
hwsrc ,
d s t=packet_arp . hwsrc )
e t h e r . s e t _ pa y l o ad ( r e p l y )
l o g . debug ( "%i %i respondendo o ARP f o r %s " %
( dpid ,
packet_in . in_port , s t r ( reply . protosrc ) ) )
123
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
#manda a mensagem r e p l y na mesma p o r t a que

chegou o request
msg . data = e t h e r . pack ( )
msg . a c t i o n s . append ( o f . o f p _ a c t i o n _ o u t p u t ( p o r t
= o f . OFPP_IN_PORT ) )
return
#para que pacotes r e p l y nao fiquem inundando na rede no l a c o sem fim
i f l e n ( s e l f . a r p _ t a b l e . keys ( ) ) != 0 :#v e r i f i c a se a t a b e l a nao ta v a z i a
i f packet_arp . p r o t o d s t i n s e l f . a r p _ t a b l e :#se j a e x i s t i r o i p de
d e s t i n o na t a b e l a
#v e r i f i c a se o time do APR na t a b e l a nao ta expirado
i f not time . time ( ) > s e l f . a r p _ t a b l e [ packet_arp . p r o t o d s t ] [ 2 ] :
#se nao t i v e r e l e NAO inunda o pacote na rede
return
#inunda o pacote na rede para todos os o u t r o s casos
l o g . debug ( "%i %i f l o o d i n g ARP %s %s => %s " % ( dpid , p a c k e t _ i n . i n _ p o r t
,
{arp . REQUEST : " request " , arp . REPLY : " r e p l y " } . get ( packet_arp .
opcode ,
op:% i % ( packet_arp . opcode , ) ) , s t r ( packet_arp . p r o t o s r c ) ,
s t r ( packet_arp . p r o t o d s t ) ) )
a c t i o n = o f . o f p _ a c t i o n _ o u t p u t ( p o r t = o f . OFPP_FLOOD )
else :
return
return
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
def r o u t e ( s e l f , packet_in , packet , dpid ) :

"""
R o t e i a o pacote I P ou ICMP dos nos da rede
U t i l i z a a t a b e l a ARP para e n c o n t r a r as p o r t a s de s a i d a s do pacote
e i n s t a l a um f l u x o no comutador com essas condicoes
"""
p a c k e t _ i p = packet . next#pega o datagrama do quadro
i f l e n ( s e l f . a r p _ t a b l e . keys ( ) ) == 0 :
l o g . warning ( " Tabela ARP vazia , pacote ignorado " )
return
# a t u a l i z a n d o o time da t a b e l a ARP
l o g . debug ( "%s %i a t u a l i z a n d o %s " , d p i d T o S t r ( dpid ) , p a c k e t _ i n . i n _ p o r t ,
packet_ip . s rc i p )
s e l f . a r p _ t a b l e [ p a c k e t _ i p . s r c i p ] = ( p a c k e t _ i n . i n _ p o r t , packet . src ,
time . time ( ) + ARP_TIMEOUT )
#v e r i f i c a se o d e s t i n o do pacote esta na t a b e l a ARP
i f packet_ip . dstip in s e l f . arp_table :
#v e r i f i c a se nao e x p i r o u
124
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
i f not time . time ( ) > s e l f . a r p _ t a b l e [ p a c k e t _ i p . d s t i p ] [ 2 ] :

#pega a p o r t a r e l a c i o n a d a com o I P de d e s t i n o
port = s e l f . arp_table [ packet_ip . dstip ] [ 0 ]
l o g . debug ( " pacote I P MAC f o n t e %s MAC d e s t i n o %s " %(packet .
src , packet . d s t ) )
l o g . debug ( " pacote I P vem da p o r t a %i " %( p a c k e t _ i n . i n _ p o r t ) )
l o g . debug ( " I P f o n t e %s I P d e s t i n o %s " %( p a c k e t _ i p . s r c i p ,
packet_ip . dstip ) )
l o g . debug ( " Enviando pacote I P para a p o r t a %i " %( p o r t ) )
#c r i a n d o a mensagem openflow de i n s t a l a c a o de f l u x o
msg . match = o f . ofp_match . from_packet ( packet , p a c k e t _ i n .
in_port )
l o g . debug ( " i n s t a l a n d o f l u x o de %s para %s para a p o r t a %i " %
( packet_ip . srcip , packet_ip . dstip , port ) )
msg . i d l e _ t i m e o u t = FLOW_IDLE_TIMEOUT
i f p a c k e t _ i n . b u f f e r _ i d != 1 and p a c k e t _ i n . b u f f e r _ i d i s not
None :
else :
return
return
else :
l o g . warning ( " Time do ARP expirado ! ! ! " )
#apaga a entrada da t a b e l a ARP
del s e l f . arp_table [ packet_ip . dstip ]
return
else :
l o g . warning ( "ARP nao encontrado na t a b e l a ! ! ! " )
169
170
171
172
173
174
175
176
177
178
179
"""
"""
dpid = event . dpid
return
180
181
182
183
i f packet_eth . type == e t h e r n e t . LLDP_TYPE :

# I g n o r a pacote LLDP
return
184
185
186
187
188
i f packet_eth . type == pkt . e t h e r n e t . ARP_TYPE :#chega um pacote ARP

l o g . debug ( " Chegou um pacote ARP no s w i t c h %s " , d p i d T o S t r ( event . dpid
))
"""
quando um pacote chega no comutador e anotado seu i p de f o n t e dado
a e l e uma tag de
125
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
t r u e com um time ( ARP_TIMEOUT ) . Quanto ao seu d e s t i n o e l e e dado

uma tag de F a l s e e
um time ( 5 ) , se em 5 segundos e l e nao e n c o n t r a r o ip , este pacote e
ignorado , p o i s e l e
nao e x i s t e na rede .
"""
#anotado o i p de f o n t e
s e l f . t a b l e _ i p [ packet_eth . next . p r o t o s r c ] = ( True , time . time ( ) +
ARP_TIMEOUT )
#se o i p de d e s t i n o e s t i v e r na t a b e l a
i f packet_eth . next . p r o t o d s t i n s e l f . t a b l e _ i p :
#se o i p de d e s t i n o f o r f a l s e
i f not s e l f . t a b l e _ i p [ packet_eth . next . p r o t o d s t ] [ 0 ] :
#se o time dele e x p i r o u
i f time . time ( ) > s e l f . t a b l e _ i p [ packet_eth . next . p r o t o d s t
][1]:
l o g . warning ( "O host com i p %s nao pode s e r encontrado
na rede " , packet_eth . next . p r o t o d s t )
return
else :
#se o i p de d e s t i n o e x p i r o u
i f time . time ( ) > s e l f . t a b l e _ i p [ packet_eth . next . p r o t o d s t
][1]:
#seta e l e como f a l s e
s e l f . t a b l e _ i p [ packet_eth . next . p r o t o d s t ] = ( False , s e l f .
t a b l e _ i p [ packet_eth . next . p r o t o d s t ] [ 1 ] )
e l s e :#se o i p de d e s t i n o nao e s t i v e r na t a b e l a
s e l f . t a b l e _ i p [ packet_eth . next . p r o t o d s t ] = ( False , time . time ( ) +
5)
#so entao e executado o p r o t o c o l o ARP
s e l f . arp_responder ( packet_in , packet_eth , dpid )
else :
l o g . debug ( " Chegou um pacote I P no s w i t c h %s " , d p i d T o S t r ( event . dpid )
)
#executado o p r o t o c o l o de roteamento
s e l f . r o u t e ( packet_in , packet_eth , dpid )
return
217
218
def launch ( ) :
219
220
221
222
Router ( event . connection )# enviamos a conexao do evento para a
classe
codigos/router.py
B.7
Cdigo do ESPECFICO
A seguir apresentado o cdigo do componente Especifico com maiores detalhes nos comentrios.
126
1
2
3
4
5
6
7
8

import pox
from pox . l i b . packet . e t h e r n e t import e t h e r n e t
from pox . l i b . packet . ipv4 import ipv4
from pox . l i b . packet . arp import arp
9
10
11
12
13
#tempos para a i n s t a l a c a o de f l u x o s
FLOW_IDLE_TIMEOUT = o f . OFP_FLOW_PERMANENT
FLOW_HARD_TIMEOUT = o f . OFP_FLOW_PERMANENT
14
15
16
17
18
19
20
class Especifico ( object ) :

21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
def i n s t a l l _ f l o w ( s e l f , d l _ t y p e , nw_dst , packet_in , packet , p o r t ) :

"""
metodo que i n s t a l a f l u x o s na t a b e l a de f l u x o s do comutador
"""
i f p o r t == 65531:
l o g . debug ( " I n s t a l a n d o f l u x o para todas as p o r t a s " )
else :
l o g . debug ( " I n s t a l a n d o f l u x o para a p o r t a %i " % p o r t )
msg . match . d l _ t y p e = d l _ t y p e
msg . match . nw_dst = nw_dst
msg . match . i n _ p o r t = p a c k e t _ i n . i n _ p o r t
msg . match . d l _ t y p e = packet . type
msg . match . d l _ s r c = packet . s r c
msg . i d l e _ t i m e o u t = FLOW_IDLE_TIMEOUT#v e j a os tempo acima
msg . hard_timeout = FLOW_HARD_TIMEOUT#v e j a os tempo acima
else :
return
return
47
48
49
50
51
52
53
def i n s t a l l _ r u l e s ( s e l f , packet_in , packet ) :

"""
metodo que i n s t a l a r e g r a s na rede toda
este componente so f u n c i o n a r a exclusivamente para essa rede , e um
componente bem
e s p e c i f i c o que j a tem determinado suas p o r t a s de entrada e s a i d a como
numero de hosts
e i p dos mesmos . Serve como exemplo de como c o n t r o l a r o f l u x o da rede .
127
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
Este componente ( j u n t o com este metodo ) f u n c i o n a em um c e n a r i o com t r e s

switches ligados
e n t r e s i , cada um em sua subrede ( 1 0 . 0 . 1 . x ; 1 0 . 0 . 2 . x ; 1 0 . 0 . 3 . x ) , cada um
com d o i s hosts
l i g a d o s nas p o r t a s 1 e 2 com i p s 1 0 . 0 . X . 2 ; 1 0 . 0 . X . 3 .
s0 l i g a d o a s1 pela p o r t a 3
Fluxo de p o r t a d e s t i n o tcp 1234 sera comutado por s0 e s1
exclusivamente p e l a s p o r t a s 3 e 3
de cada switch , os demais pacotes nao poderao usar este caminho para
f l u x o de dados , todos os dados
deverao c o n t o r n a r a rede . ( Ex . f l u x o normal de s0 para s1 devera passar
por s2 )
"""
#pega o proximo cabecaolho
p=packet . next
#v e r i f i c a se o pacote e ipv4 ou arp e pega seus i p s
i f i s i n s t a n c e ( p , ipv4 ) :
nw_src = p . s r c i p
nw_dst = p . d s t i p
d l _ t y p e = 0x0800
p = p . next
e l i f i s i n s t a n c e ( p , arp ) :
i f p . opcode <= 255:
nw_src = p . p r o t o s r c
nw_dst = p . p r o t o d s t
d l _ t y p e = 0x0806
else :
return
#sendo qualquer o u t r a c o i s a r e t o r n a
else :
return
#comeca as a t r i b u i c o e s de caminho
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 2 ] != ( s t r ( nw_src ) . s p l i t ( . ) ) [ 2 ] :
#esse caso e quando o d e s t i n o nao e l o c a l
i f ( s t r ( nw_src ) . s p l i t ( . ) ) [ 2 ] == " 1 " :
#esse caso e quando a f o n t e e de s0
i f p a c k e t _ i n . i n _ p o r t == 1 or p a c k e t _ i n . i n _ p o r t == 2 :#ta no s0
mesmo
i f packet . f i n d ( " tcp " ) != None and ( packet . f i n d ( " tcp " ) .
d s t p o r t == 1234 or packet . f i n d ( " tcp " ) . s r c p o r t == 1234) :
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 2 ] == " 2 " :#se o d e s t i n o e
s1
s e l f . i n s t a l l _ f l o w ( d l _ t y p e , nw_dst , packet_in ,
packet , 3)
return
e l s e :#o d e s t i n o e s2
packet , 4)
return
else :
128
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
s e l f . i n s t a l l _ f l o w ( d l _ t y p e , nw_dst , packet_in , packet ,

4)
return
e l i f p a c k e t _ i n . i n _ p o r t == 4 :#ta no s1 d e s t i n o do s1
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 3 ] == " 2 " :
1)
return
else :
2)
return
e l s e :#ta no s2 ou no s1 ( tcp p o r t 1234)
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 2 ] == " 3 " :#se o d e s t i n o e de s2
de 3.2
packet , 1)
return
else :
packet , 2)
return
e l s e :#d e s t i n o nao e de s2 entao e de s1
#se e l e tem a p o r t tcp 1234 e f o n t e s0 entao e l e chegou
pela p o r t a 3 e j a esta no s1
d s t p o r t == 1234 or packet . f i n d ( " tcp " ) . s r c p o r t ==
1234) :
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 3 ] == " 2 " :# se o
d e s t i n o e 2.2
packet , 1)
return
e l s e :#se o d e s t i n o e 2.3
packet , 2)
return
e l s e :#f o n t e s0 passando pelo s2 com d e s t i n o a s1
packet , 4)
return
e l i f ( s t r ( nw_src ) . s p l i t ( . ) ) [ 2 ] == " 2 " :
mesmo
d s t p o r t == 1234 or packet . f i n d ( " tcp " ) . s r c p o r t == 1234) :
s0
packet , 3)
return
e l s e :#o d e s t i n o e s2
packet , 4)
129
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
return
else :
4)
return
e l i f p a c k e t _ i n . i n _ p o r t == 4 :#pode s e r o s0 ou o s2 inunda
s e l f . i n s t a l l _ f l o w ( d l _ t y p e , nw_dst , packet_in , packet , o f .
OFPP_FLOOD )
else :
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 2 ] == " 1 " :#se o d e s t i n o e s0
1.2
packet , 1)
return
else :
packet , 2)
return
else :
return
e l i f ( s t r ( nw_src ) . s p l i t ( . ) ) [ 2 ] == " 3 " :
mesmo
i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 2 ] == " 1 " :
3)
return
else :
4)
return
e l i f p a c k e t _ i n . i n _ p o r t == 4 :#pode s e r o s0 ou o s1 inunda
s e l f . i n s t a l l _ f l o w ( d l _ t y p e , nw_dst , packet_in , packet , o f .
OFPP_FLOOD )
return
else :
return
else :
return
#esse caso e quando o d e s t i n o e l o c a l , bastando o l h a r seu d e s t i n o (
u l t i m o q u a r t e t o do i p )
e l i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 3 ] == " 2 " :#para a p o r t a 1
s e l f . i n s t a l l _ f l o w ( d l _ t y p e , nw_dst , packet_in , packet , 1)
return
e l i f ( s t r ( nw_dst ) . s p l i t ( . ) ) [ 3 ] == " 3 " :#para a p o r t a 2
s e l f . i n s t a l l _ f l o w ( d l _ t y p e , nw_dst , packet_in , packet , 2)
return
#qualquer o u t r o caso r e t o r n a
else :
return
180
181
182
183
"""
130
184
185
186
"""
187
188
189
190

return
191
192
193
194
i f packet_eth . type == e t h e r n e t . LLDP_TYPE :

# I g n o r a pacote LLDP
return
195
196
197
198
#i n s t a l a as r e g r a s a medida que os pacotes chegam no comutador e vao

para o c o n t r o l a d o r
s e l f . i n s t a l l _ r u l e s ( packet_in , packet_eth )
return
199
200
def launch ( ) :
201
202
203
204
E s p e c i f i c o ( event . connection )# enviamos a conexao do evento para a
classe
codigos/especifico.py
131
Apndice C
API MiniNet (MiniGUI)
Este o cdigo utilizado para a criao da API MiniGUI criada neste trabalho que
tem como objetivo fornecer uma interface grfica para a inicializao do CLI do MiniNet. Caso tenha alguma dvida sobre as opes de inicializao do CLI do MiniNet
consulte o capitulo 6. A interface mostra as opes de inicializao do CLI do MiniNet
e inicia o CLI no Shell. Pode ser til para quem comea a utilizar o MiniNet e no
conhece ou lembra todas as opes de inicializao.
Para executar esta API, crie um arquivo com o nome de minigui.py no diretrio
mininet/examples (por exemplo) e execute-o na mquina virtual da seguinte maneira:
$ sudo python -O /mininet/examples/minigui.py
Pode-se utilizar para entender melhor a estrutura do MiniNet. Esta interface grfica foi criada com a utilizao da biblioteca Tkinter do Python, seu cdigo pode ser
visto a seguir. A interface auto explicativa (Figura C.1).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
"""
THE MININET GUI
author : Lucas Costa ( l u c a s r c . rodri@gmail . com)
"""
import os
import commands
import sys
from mininet . clean import cleanup
from mininet . c l i import C L I
from mininet . l o g import lg , LEVELS , i n f o , s e t L o g L e v e l
from mininet . net import Mininet , i n i t
from mininet . node import KernelSwitch , Host , C o n t r o l l e r , C on t ro l l er P a ra m s ,
NOX
from mininet . node import RemoteController , UserSwitch , OVSKernelSwitch
from mininet . topo import SingleSwitchTopo , LinearTopo ,
SingleSwitchReversedTopo
from mininet . t o p o l i b import TreeTopo
from mininet . u t i l import makeNumeric
132
Figura C.1: MiniGUI API minigui.py (API de inicializao do CLI do MiniNet).

17
18
from T k i n t e r import
from t k F i l e D i a l o g import askopenfilename
19
20
21
22
23
24
25
26
27
28
29
30
31
class curry :
def _ _ i n i t _ _ ( s e l f , fun , args , kwargs ) :
s e l f . fun = fun
s e l f . pending = args [ : ]
s e l f . kwargs = kwargs . copy ( )
def _ _ c a l l _ _ ( s e l f , args , kwargs ) :
i f kwargs and s e l f . kwargs :
kw = s e l f . kwargs . copy ( )
kw . update ( kwargs )
else :
kw = kwargs or s e l f . kwargs
r e t u r n s e l f . fun ( ( s e l f . pending + args ) , kw )
32
33
34
def event_lambda ( f , args , kwds ) :

r e t u r n lambda event , f=f , args=args , kwds=kwds : f ( args , kwds )
35
36
37
38
39
40
41
c l a s s MiniNetGui :
def _ _ i n i t _ _ ( s e l f , parent ) :
s e l f . mininet = None
se lf . controller = IntVar ( )
s e l f . switch = IntVar ( )
s e l f . topology = I n t V a r ( )
133
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
se lf . script = IntVar ( )
s e l f . xterm = I n t V a r ( )
self . controller = 1
s e l f . switch = 2
s e l f . topology = 3
s e l f . s c r i p t = 10
s e l f . xterm = 20
s e l f . mac = 31
s e l f . ping = 40
s e l f . i p e r f = 50
s e l f . f i l e n a m e _ t o p o = None
s e l f . f i l e n a m e _ s c r i p t = None
s e l f . myLastButtonInvoked = None
parent . t i t l e ( " MININET by Lucas " )
s e l f . myParent = parent
###t o t a l frame
s e l f . myframe = Frame ( parent )
s e l f . myframe . pack ( )
###t o t a l frame
###top frame
s e l f . top_frame = Frame ( s e l f . myframe , pady=" 3m" )
s e l f . top_frame . pack ( )
###top frame
###middle frame
s e l f . middle_frame = Frame ( s e l f . myframe , r e l i e f =RIDGE , h e i g h t =150,
width =300)
s e l f . middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE)
###middle frame
###bottom frame
s e l f . bottom_frame = Frame ( s e l f . myframe , r e l i e f =RIDGE , h e i g h t =150,
width =300)
s e l f . bottom_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE, anchor=W)
###bottom frame
###buttons frame
s e l f . buttons_frame = Frame ( s e l f . myframe , r e l i e f =RIDGE , h e i g h t =75,
width =300,pady=" 3m" )
s e l f . buttons_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE, anchor=E )
###buttons frame
###c o n t r o l l e r frame
s e l f . top1_middle_frame = Frame ( s e l f . middle_frame , r e l i e f =RIDGE ,
h e i g h t =120, width =300)
s e l f . top1_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE, anchor=
W, pady=" 3m" )
s e l f . top_top1_middle_frame = Frame ( s e l f . top1_middle_frame , r e l i e f =
RIDGE , h e i g h t =60, width =300)
s e l f . top_top1_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W)
s e l f . bottom_top1_middle_frame = Frame ( s e l f . top1_middle_frame , r e l i e f
=RIDGE , h e i g h t =60, width =300)
s e l f . bottom_top1_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W)
###c o n t r o l l e r frame
###s w i t c h frame
s e l f . top2_middle_frame = Frame ( s e l f . middle_frame , r e l i e f =RIDGE ,
h e i g h t =120, width =300)
134
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
s e l f . top2_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE, anchor=

W)
s e l f . top_top2_middle_frame = Frame ( s e l f . top2_middle_frame , r e l i e f =
RIDGE , h e i g h t =60, width =300)
s e l f . top_top2_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W)
###s w i t c h frame
###topology frame
s e l f . middle_middle_frame = Frame ( s e l f . middle_frame , r e l i e f =RIDGE ,
h e i g h t =50, width =300)
s e l f . middle_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE, pady="
3m" )
s e l f . frm1_middle_middle_frame = Frame ( s e l f . middle_middle_frame ,
r e l i e f =RIDGE , h e i g h t =10, width =300)
s e l f . frm1_middle_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W)
anchor=W)
anchor=W)
anchor=W)
anchor=W)
anchor=E )
###topology frame
###s c r i p t frame
s e l f . bottom_middle_frame = Frame ( s e l f . middle_frame , r e l i e f =RIDGE ,
h e i g h t =50, width =300)
s e l f . bottom_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W, pady=" 3m" )
s e l f . frm1_bottom_middle_frame = Frame ( s e l f . bottom_middle_frame ,
s e l f . frm1_bottom_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W)
s e l f . frm2_bottom_middle_frame = Frame ( s e l f . bottom_middle_frame ,
s e l f . frm2_bottom_middle_frame . pack ( s i d e=TOP , expand=NO, f i l l =NONE,
anchor=W)
###s c r i p t frame
###o p t i o n s frame
s e l f . top_bottom_frame = Frame ( s e l f . bottom_frame , r e l i e f =RIDGE , h e i g h t
=75, width =300,pady=" 3m" )
s e l f . top_bottom_frame . pack ( s i d e=TOP , anchor=W)
135
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
s e l f . t o p _ b o t t o m _ l e f t _ f r a m e = Frame ( s e l f . top_bottom_frame , r e l i e f =
RIDGE , h e i g h t =75, width =300,pady=" 3m" )
s e l f . t o p _ b o t t o m _ l e f t _ f r a m e . pack ( s i d e=LEFT , anchor=W)
s e l f . t o p _ b o t t o m _ r i g h t _ f r a m e = Frame ( s e l f . top_bottom_frame , r e l i e f =
RIDGE , h e i g h t =75, width =300,pady=" 3m" , padx=" 3m" )
s e l f . t o p _ b o t t o m _ r i g h t _ f r a m e . pack ( s i d e=LEFT , anchor=W)
###o p t i o n s frame
### t i t l e
s e l f . t e x t _ t i t l e = Label ( s e l f . top_frame , t e x t="THE MININET GUI " ,
f o n t = ( Times , 16 , bold ) )
s e l f . t e x t _ t i t l e . pack ( s i d e=" top " , f i l l =" both " , expand=True )
### t i t l e
###c o n t r o l l e r args
s e l f . t e x t _ c o n t r o l l e r = Label ( s e l f . top_top1_middle_frame , t e x t="
C o n t r o l l e r Type : " , f o n t = ( Times , 12 , bold ) )
s e l f . t e x t _ c o n t r o l l e r . pack ( s i d e=" top " , anchor=W)
s e l f . r a d i o 1 _ c o n t r o l l e r = Radiobutton ( s e l f . top_top1_middle_frame ,
t e x t=" C o n t r o l l e r r e f " , v a r i a b l e=s e l f . c o n t r o l l e r ,
command=lambda c o n t r o l l e r = 1
: self . radioController (
controller ) )
s e l f . r a d i o 1 _ c o n t r o l l e r . pack ( s i d e=" top " , anchor=W)
self . radio1_controller . select ()
s e l f . r a d i o 2 _ c o n t r o l l e r = Radiobutton ( s e l f . top_top1_middle_frame ,
t e x t=" C o n t r o l l e r remote " , v a r i a b l e=s e l f . c o n t r o l l e r ,
value =5,command=lambda
controller = 2 : self .
radioController ( controller )
)
s e l f . r a d i o 2 _ c o n t r o l l e r . pack ( s i d e=" top " , anchor=W)
s e l f . r a d i o 3 _ c o n t r o l l e r = Radiobutton ( s e l f . bottom_top1_middle_frame ,
t e x t=" C o n t r o l l e r remote i p = " , v a r i a b l e=s e l f . c o n t r o l l e r ,
controller = 3 : self .
radioController ( controller )
)
s e l f . r a d i o 3 _ c o n t r o l l e r . pack ( s i d e=" l e f t " , anchor=W)
s e l f . t e x t _ i p _ c o n t r o l l e r = E n t r y ( s e l f . bottom_top1_middle_frame ,
width =15,background= gray )
s e l f . t e x t _ i p _ c o n t r o l l e r . pack ( s i d e=" l e f t " , f i l l =" both " , expand=True ,
anchor=E )
s e l f . t e x t _ i p _ c o n t r o l l e r . c o n f i g ( s t a t e=DISABLED )
###c o n t r o l l e r args
###s w i t c h args
s e l f . t e x t _ s w i t c h = Label ( s e l f . top_top2_middle_frame , t e x t=" Switch
Type : " , f o n t = ( Times , 12 , bold ) )
s e l f . t e x t _ s w i t c h . pack ( s i d e=" top " , anchor=W)
s e l f . r a d i o 1 _ s w i t c h = Radiobutton ( s e l f . top_top2_middle_frame , t e x t="
Switch k e r n e l " , v a r i a b l e=s e l f . switch ,
command=lambda s w i t c h = 1 :
s e l f . radioSwitch ( switch ) )
s e l f . r a d i o 1 _ s w i t c h . pack ( s i d e=" top " , anchor=W)
s e l f . r a d i o 1 _ s w i t c h . c o n f i g ( s t a t e=DISABLED )### The k e r n e l s w i t c h t h i s
o f f i n t h i s v e r s i o n###
Switch ovsk " , v a r i a b l e=s e l f . switch ,
136
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
value =7,command=lambda s w i t c h
= 2 : s e l f . radioSwitch (
switch ) )
s e l f . r a d i o 2 _ s w i t c h . pack ( s i d e=" top " , anchor=W)
s e l f . radio2_switch . select ( )
Switch user " , v a r i a b l e=s e l f . switch ,
value =8,command=lambda s w i t c h
= 3 : s e l f . radioSwitch (
switch ) )
s e l f . r a d i o 3 _ s w i t c h . pack ( s i d e=" l e f t " , anchor=W)
###s w i t c h args
###topology args
s e l f . t e x t _ t o p o l o g y = Label ( s e l f . frm1_middle_middle_frame , t e x t="
Topology Type : " , f o n t = ( Times , 12 , bold ) )
s e l f . t e x t _ t o p o l o g y . pack ( s i d e=" top " , anchor=W)
###
s e l f . r a d i o 1 _ t o p o l o g y = Radiobutton ( s e l f . frm2_middle_middle_frame ,
t e x t=" l i n e a r " , v a r i a b l e=s e l f . topology ,
command=lambda topology = 1 :
s e l f . radioTopology ( topology
))
s e l f . r a d i o 1 _ t o p o l o g y . pack ( s i d e=" l e f t " , anchor=W)
s e l f . t e x t 1 _ t o p o l o g y = E n t r y ( s e l f . frm2_middle_middle_frame , width =4,
background= gray )
s e l f . t e x t 1 _ t o p o l o g y . pack ( s i d e=" l e f t " , f i l l =" both " , expand=True ,
anchor=E )
s e l f . text1_topology . i n s e r t (0 , "2" )
s e l f . t e x t 1 _ t o p o l o g y . c o n f i g ( s t a t e=DISABLED )
###
###
t e x t=" t r e e " , v a r i a b l e=s e l f . topology ,
topology = 2 : s e l f .
radioTopology ( topology ) )
s e l f . t e x t 2 1 _ t o p o l o g y = E n t r y ( s e l f . frm3_middle_middle_frame , width =4,
background= gray )
s e l f . t e x t 2 1 _ t o p o l o g y . pack ( s i d e=" l e f t " , f i l l =" both " , expand=True ,
anchor=E )
s e l f . t e x t 2 1 _ t o p o l o g y . c o n f i g ( s t a t e=DISABLED )
s e l f . t e x t 2 2 _ t o p o l o g y = E n t r y ( s e l f . frm3_middle_middle_frame , width =4,
background= gray )
s e l f . t e x t 2 2 _ t o p o l o g y . pack ( s i d e=" l e f t " , f i l l =" both " , expand=True ,
anchor=E )
###
###
t e x t=" s i n g l e " , v a r i a b l e=s e l f . topology ,
137
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224

s e l f . radio3_topology . select ( )
background= white )
anchor=E )
###
###
t e x t=" custom " , v a r i a b l e=s e l f . topology ,
background= gray )
anchor=E )
s e l f . b u t t o n _ t o p o l o g y = Button ( s e l f . frm5_middle_middle_frame , command
=s e l f . b u t t o n _ t o p o l o g y )
s e l f . b u t t o n _ t o p o l o g y . c o n f i g u r e ( t e x t=" browser " , h e i g h t =1, padx=" 0m" ,
pady=" 0m" )
s e l f . b u t t o n _ t o p o l o g y . pack ( s i d e=" l e f t " )
s e l f . b u t t o n _ t o p o l o g y . bind ( "<Return>" , s e l f . b u t t o n _ t o p o l o g y _ a )
s e l f . b u t t o n _ t o p o l o g y . c o n f i g ( s t a t e=DISABLED )
s e l f . text_custom = Label ( s e l f . frm6_middle_middle_frame , t e x t=" The
c l a s s must have the name o f Mytopo ! ! ! " , f o n t = ( Times , 11 ,
bold ) )
s e l f . text_custom . pack ( s i d e=" top " , anchor=E )
###
###topology args
###s c r i p t args
s e l f . t e x t _ s c r i p t = Label ( s e l f . frm1_bottom_middle_frame , t e x t="
S c r i p t : " , f o n t = ( Times , 12 , bold ) )
s e l f . t e x t _ s c r i p t . pack ( s i d e=" top " , anchor=W)
s e l f . c h e c k _ s c r i p t = Checkbutton ( s e l f . frm2_bottom_middle_frame ,
v a r i a b l e=s e l f . s c r i p t , command=s e l f . c h e c k S c r i p t )
s e l f . c h e c k _ s c r i p t . pack ( s i d e=" l e f t " , anchor=W)
s e l f . t e x t _ s c r i p t = E n t r y ( s e l f . frm2_bottom_middle_frame , width =37,
background= gray )
s e l f . t e x t _ s c r i p t . pack ( s i d e=" l e f t " , f i l l =" both " , expand=True , anchor
=E )
s e l f . t e x t _ s c r i p t . c o n f i g ( s t a t e=DISABLED )
s e l f . b u t t o n _ s c r i p t = Button ( s e l f . frm2_bottom_middle_frame , command=
self . button_script )
s e l f . b u t t o n _ s c r i p t . c o n f i g u r e ( t e x t=" browser " , h e i g h t =1, padx=" 0m" ,
pady=" 0m" )
s e l f . b u t t o n _ s c r i p t . pack ( s i d e=" l e f t " )
s e l f . b u t t o n _ s c r i p t . bind ( "<Return>" , s e l f . b u t t o n _ s c r i p t _ a )
s e l f . b u t t o n _ s c r i p t . c o n f i g ( s t a t e=DISABLED )
###s c r i p t args
###o p t i o n s args
s e l f . t e x t _ a c t i v e = Label ( s e l f . t o p _ b o t t o m _ l e f t _ f r a m e , t e x t=" A c t i v e : "
, f o n t = ( Times , 12 , bold ) )
138
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
s e l f . t e x t _ a c t i v e . pack ( s i d e=" top " , anchor=W)

s e l f . check_xterm = Checkbutton ( s e l f . t o p _ b o t t o m _ l e f t _ f r a m e , t e x t="
xterm " , v a r i a b l e=s e l f . xterm , command=s e l f . checkXterm )
s e l f . check_xterm . pack ( s i d e=" l e f t " , anchor=W)
s e l f . check_mac = Checkbutton ( s e l f . t o p _ b o t t o m _ l e f t _ f r a m e , t e x t="
mac" , v a r i a b l e=s e l f . mac , command=s e l f . checkMac )
s e l f . check_mac . s e l e c t ( )
s e l f . check_mac . pack ( s i d e=" top " , anchor=W)
s e l f . t e x t _ t e s t s = Label ( s e l f . top_bottom_right_frame , t e x t=" T e s t s : " ,
f o n t = ( Times , 12 , bold ) )
s e l f . t e x t _ t e s t s . pack ( s i d e=" top " , anchor=W)
s e l f . check_ping = Checkbutton ( s e l f . top_bottom_right_frame , t e x t="
p i n g a l l " , v a r i a b l e=s e l f . ping , command=s e l f . checkPing )
s e l f . check_ping . pack ( s i d e=" l e f t " , anchor=W)
s e l f . c h e c k _ i p e r f = Checkbutton ( s e l f . top_bottom_right_frame , t e x t="
i p e r f " , v a r i a b l e=s e l f . i p e r f , command=s e l f . c h e c k I p e r f )
s e l f . c h e c k _ i p e r f . pack ( s i d e=" top " , anchor=W)
###o p t i o n s args
###buttons args
s e l f . button1 = Button ( s e l f . buttons_frame , command=s e l f . buttonRun ,
f o n t = ( Times , 12 , bold ) )
s e l f . button1 . c o n f i g u r e ( t e x t=" Run MiniNet " , h e i g h t =1, width =15)
s e l f . button1 . pack ( s i d e=" top " , anchor=SE )
s e l f . button1 . bind ( "<Return>" , s e l f . buttonRun_a )
s e l f . button1 . f o c u s _ f o r c e ( )
s e l f . button2 = Button ( s e l f . buttons_frame , command=s e l f . buttonClose ,
f o n t = ( Times , 12 , bold ) )
s e l f . button2 . c o n f i g u r e ( t e x t=" Close GUI " , h e i g h t =1, width =15)
s e l f . button2 . pack ( s i d e=" top " , anchor=SE )
s e l f . button2 . bind ( "<Return>" , s e l f . buttonClose_a )
###buttons args
249
250
251
252
253
254
255
256
257
258
259
260
261
def setCustom ( s e l f , name , value ) :

" Set custom parameters f o r MininetRunner . "
i f name i n ( TOPOS , s w i t c h e s , hosts , c o n t r o l l e r s ) :
# Update d i c t i o n a r i e s
param = name . upper ( )
g l o b a l s ( ) [ param ] . update ( value )
e l i f name == v a l i d a t e :
# Add custom v a l i d a t e f u n c t i o n
s e l f . v a l i d a t e = value
else :
# Add or modify g l o b a l v a r i a b l e or c l a s s
g l o b a l s ( ) [ name ] = value
262
263
264
265
266
267
268
269
270
271
def parseCustomFile ( s e l f , fileName ) :

" Parse custom f i l e and add params before p a r s i n g cmdl i n e o p t i o n s . "
custom = {}
i f os . path . i s f i l e ( fileName ) :
e x e c f i l e ( fileName , custom , custom )
f o r name i n custom :
s e l f . setCustom ( name , custom [ name ] )
else :
r a i s e Exception ( could not f i n d custom f i l e : %s % fileName )
272
273
def buttonClose ( s e l f ) :
139
274
s e l f . myParent . d e s t r o y ( )
275
276
277
def buttonClose_a ( s e l f , event ) :

s e l f . button2Click ( )
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
def buttonRun ( s e l f ) :
print " \n
"
p r i n t " do not f o r g e t to e x i t the C L I with the command < C t r l >+D or
exit "
print "
\
n"
i p c o n t r o l l e r = StringVar ( )
i p c o n t r o l l e r = s e l f . t e x t _ i p _ c o n t r o l l e r . get ( )
i f i p c o n t r o l l e r == " " :
i p c o n t r o l l e r = " 127.0.0.1 "
l i n e a r t o p o = s e l f . t e x t 1 _ t o p o l o g y . get ( )
i f l i n e a r t o p o == " " :
lineartopo = 2
treetopo_depth = s e l f . t e x t 2 1 _ t o p o l o g y . get ( )
i f treetopo_depth == " " :
treetopo_depth = 1
t r e e t o p o _ f a n o u t = s e l f . t e x t 2 2 _ t o p o l o g y . get ( )
i f t r e e t o p o _ f a n o u t == " " :
treetopo_fanout = 2
s i n g l e t o p o = s e l f . t e x t 3 _ t o p o l o g y . get ( )
i f s i n g l e t o p o == " " :
singletopo = 2
i f s e l f . xterm == 20:
x = False
else :
x = True
i f s e l f . mac == 30:
m = False
else :
m = True
#checks the topology s e l e c t e d
i f s e l f . topology == 1 :
topo = LinearTopo ( k =i n t ( l i n e a r t o p o ) )
e l i f s e l f . topology == 2 :
topo = TreeTopo ( depth=i n t ( treetopo_depth ) )
e l i f s e l f . topology == 3 :
topo = SingleSwitchTopo ( k=i n t ( s i n g l e t o p o ) )
else :
#The c l a s s must have the name o f Mytopo
s e l f . parseCustomFile ( s e l f . f i l e n a m e _ t o p o )
topo = MyTopo ( )
#checks the s e l e c t e d s w i t c h
i f s e l f . s w i t c h == 1 :
switch = KernelSwitch
e l i f s e l f . s w i t c h == 2 :
s w i t c h = OVSKernelSwitch
else :
s w i t c h = UserSwitch
140
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
#checks the s e l e c t e d c o n t r o l l e r
i f s e l f . c o n t r o l l e r == 1 :
controller = Controller
e l i f s e l f . c o n t r o l l e r == 2 :
c o n t r o l l e r = RemoteController
else :
c o n t r o l l e r = c u r r y ( RemoteController , d e f a u l t I P=i p c o n t r o l l e r )
#c r e a t i n g the network
net = M i n i n e t ( topo = topo , c o n t r o l l e r = c o n t r o l l e r , s w i t c h =
switch , autoSetMacs=m, cleanup=True , xterms=x )
#s t a r t the network
net . s t a r t ( )
i f s e l f . ping == 41:
net . p i n g A l l ( )
i f s e l f . i p e r f == 51:
net . i p e r f ( )
print " \n
"
p r i n t " don t f o r g e t to e x i t the C L I with the command < C t r l >+D or
exit "
print "
\
n"
i n f o ( Running C L I \ n )
i f s e l f . f i l e n a m e _ s c r i p t == None :
C L I ( net )
else :
C L I ( net , s c r i p t=s e l f . f i l e n a m e _ s c r i p t )
C L I ( net )
i n f o ( Stopping network )
net . stop ( )
351
352
353
def buttonRun_a ( s e l f , event ) :

s e l f . buttonRun ( )
354
355
356
357
358
def b u t t o n _ t o p o l o g y ( s e l f ) :
s e l f . f i l e n a m e _ t o p o = askopenfilename ( f i l e t y p e s =[( " a l l f i l e s " , " " ) , ( "
p y t h o n f i l e s " , " . py " ) ] )
s e l f . t e x t 4 _ t o p o l o g y . d e l e t e ( 0 , END)
s e l f . text4_topology . i n s e r t (0 , s e l f . filename_topo )
359
360
361
def b u t t o n _ t o p o l o g y _ a ( s e l f , event ) :
s e l f . button_topology ( )
362
363
364
365
366
def b u t t o n _ s c r i p t ( s e l f ) :
s e l f . f i l e n a m e _ s c r i p t = askopenfilename ( f i l e t y p e s =[( " a l l f i l e s " , " " )
, ( " p y t h o n f i l e s " , " . py " ) ] )
s e l f . t e x t _ s c r i p t . d e l e t e ( 0 ,END)
s e l f . t e x t _ s c r i p t . insert (0 , s e l f . filename_script )
367
368
369
def b u t t o n _ s c r i p t _ a ( s e l f , event ) :
self . button_script ()
370
371
372
def r a d i o C o n t r o l l e r ( s e l f , c o n t r o l l e r ) :
i f c o n t r o l l e r == 3 :
141
373
374
375
376
377
378
379
s e l f . t e x t _ i p _ c o n t r o l l e r . c o n f i g ( s t a t e=NORMAL)
s e l f . t e x t _ i p _ c o n t r o l l e r . c o n f i g u r e ( background= white )
else :
s e l f . t e x t _ i p _ c o n t r o l l e r . d e l e t e ( 0 , END)
s e l f . t e x t _ i p _ c o n t r o l l e r . c o n f i g ( s t a t e=DISABLED )
s e l f . t e x t _ i p _ c o n t r o l l e r . c o n f i g u r e ( background= gray )
self . controller = controller
380
381
382
def r a d i o S w i t c h ( s e l f , s w i t c h ) :
s e l f . switch = switch
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
def radioTopology ( s e l f , topology ) :

i f topology == 1 :
s e l f . t e x t 1 _ t o p o l o g y . c o n f i g ( s t a t e=NORMAL)
s e l f . t e x t 1 _ t o p o l o g y . c o n f i g u r e ( background= white )
s e l f . t e x t 2 1 _ t o p o l o g y . c o n f i g u r e ( background= gray )
s e l f . t e x t 3 _ t o p o l o g y . c o n f i g u r e ( background= gray )
e l i f topology == 2 :
s e l f . t e x t 2 1 _ t o p o l o g y . c o n f i g ( s t a t e=NORMAL)
s e l f . t e x t 2 1 _ t o p o l o g y . c o n f i g u r e ( background= white )
s e l f . t e x t 2 2 _ t o p o l o g y . c o n f i g ( s t a t e=NORMAL)
s e l f . t e x t 2 2 _ t o p o l o g y . c o n f i g u r e ( background= white )
e l i f topology == 3 :
s e l f . t e x t 3 _ t o p o l o g y . c o n f i g ( s t a t e=NORMAL)
s e l f . t e x t 3 _ t o p o l o g y . c o n f i g u r e ( background= white )
else :
422
423
424
425
426
427
428
self
self
self
self
self
self
. t e x t 4 _ t o p o l o g y . c o n f i g ( s t a t e=NORMAL)
. t e x t 4 _ t o p o l o g y . c o n f i g u r e ( background= white )
. b u t t o n _ t o p o l o g y . c o n f i g ( s t a t e=NORMAL)
. t e x t 1 _ t o p o l o g y . c o n f i g ( s t a t e=DISABLED )
. t e x t 1 _ t o p o l o g y . c o n f i g u r e ( background= gray )
. t e x t 2 1 _ t o p o l o g y . c o n f i g ( s t a t e=DISABLED )
142
429
430
431
432
433
434
s e l f . topology = topology
435
436
437
438
439
440
441
442
443
444
445
446
447
448
def c h e c k S c r i p t ( s e l f ) :
i f s e l f . s c r i p t == 10:
s e l f . s c r i p t = 11
s e l f . t e x t _ s c r i p t . c o n f i g ( s t a t e=NORMAL)
s e l f . t e x t _ s c r i p t . c o n f i g u r e ( background= white )
s e l f . b u t t o n _ s c r i p t . c o n f i g ( s t a t e=NORMAL)
else :
s e l f . s c r i p t = 10
s e l f . t e x t _ s c r i p t . d e l e t e ( 0 , END)
s e l f . t e x t _ s c r i p t . c o n f i g ( s t a t e=DISABLED )
s e l f . t e x t _ s c r i p t . c o n f i g u r e ( background= gray )
s e l f . b u t t o n _ s c r i p t . c o n f i g ( s t a t e=DISABLED )
s e l f . f i l e n a m e _ s c r i p t = None
449
450
451
452
453
454
def checkXterm ( s e l f ) :
i f s e l f . xterm == 20:
else :
455
456
457
458
459
460
def checkMac ( s e l f ) :
i f s e l f . mac == 30:
s e l f . mac = 31
else :
s e l f . mac = 30
461
462
463
464
465
466
def checkPing ( s e l f ) :
i f s e l f . ping == 40:
s e l f . ping = 41
else :
s e l f . ping = 40
467
468
469
470
471
472
def c h e c k I p e r f ( s e l f ) :
i f s e l f . i p e r f == 50:
s e l f . i p e r f = 51
else :
s e l f . i p e r f = 50
473
474
475
476
477
478
479
480
481
i f __name__ == __main__ :
p r i n t " \ n " 100
print " Starting . . . "
r o o t = Tk ( )
myapp = MiniNetGui ( r o o t )
r o o t . mainloop ( )
p r i n t " . . . Done ! "
codigos/minigui.py
143

Monografia Vesao Leitura em PC PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Monografia Vesao Leitura em PC PDF

Загружено:

Авторское право:

Доступные форматы

Universidade de Braslia

Instituto de Cincias Exatas

OpenFlow e o Paradigma de Redes Definidas por

Lucas Rodrigues Costa

Monografia apresentada como requisito parcial

Universidade de Braslia UnB

Coordenador: Prof. Dr. Flvio de Barros Vidal

Banca examinadora composta por:

CIP Catalogao Internacional na Publicao

OpenFlow e o Paradigma de Redes Definidas por

Lucas Rodrigues Costa

Monografia apresentada como requisito parcial

Prof. Dr. Andr Costa Drummond (Orientador)

Prof. Dr. Jacir Luiz Bordim

Prof. Dr. Wilson Henrique Veneziano

Prof. Dr. Flvio de Barros Vidal

Braslia, 8 de maro de 2013

3 Redes Definidas por Software

3.7.5 Redes Domsticas . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A Descrio dos Elementos do POX

C API MiniNet (MiniGUI)

Diferenas entre as topologias do sistema telefnico e da ARPANET.

Arquiteturas de roteadores: modelo atual e modelo programvel [40].

4.1 Componentes de uma rede OpenFlow [33]. . . . . . . . . . . . . . . . . 43

O sucesso das redes de computadores evidenciou o trabalho de pesquisadores

nistradores de rede. Todas essas barreiras dificultam a implantao de novas ideias

Este trabalho tem como objetivos gerais:

O restante do trabalho est organizado da seguinte forma. O Captulo 2 traz o

Histria das Redes de Computadores

As Redes de Computadores surgiram a partir de pesquisas militares no perodo

(a) Exemplo de Topologia Estrela

(b) Exemplo de Topologia Malha

Figura 2.1: Diferenas entre as topologias do sistema telefnico e da ARPANET.

resolvessem este problema, esse esforo resultou na criao dos protocolos e do

Ao passar dos anos as redes de computadores foram crescendo tornando-se um

Figura 2.2: Pilha TCP/IP.

Figura 2.3: Protocolo TCP/IP [31].

O transporte fim-a-fim prov a comunicao lgica entre os processos de aplicao

Um ISP de nvel 2 normalmente tem alcance regional ou nacional e conectam-se

Evoluo das Redes de Computadores

Simple Network Management Protocol - SNMP um protocolo de gerenciamento de rede que

se basicamente a monitorao dos dispositivos da rede fornecendo apenas um

Como foi apresentado, as modificaes realizadas na arquitetura da rede atual

As sees anteriores mostraram que a simplicidade da arquitetura atual das redes

Essa abordagem assemelha-se a arquitetura atual das redes de computadores

(a) Arquitetura Atual e Purista

(b) Arquitetura Pluralista

Figura 2.4: Representao dos tipos de arquitetura da Internet do Futuro [17].

ras em um nico arcabouo consistente, visto que essas arquiteturas em geral so

Como j apresentado, a injeo de novas ideias e implementaes no ncleo da

Redes Definidas por Software

Mesmo com o grande crescimento e evoluo da Internet, observamos que sua

problemas atuais e futuros. Uma das formas de se prover programabilidade s redes

As redes virtualizadas como a GENI so interessantes para diminuir as barreiras

perimentao de novas propostas para redes de computadores em escalas menores,

Figura 2.6: Arquitetura do comutador OpenFlow [42].

Sugimento das Redes Definidas por Software

A arquitetura atual do roteadores de rede (Figura 3.1) formada basicamente por

Figura 3.1: Arquiteturas de roteadores: modelo atual e modelo programvel [40].

Elementos Programveis das redes SDN

De maneira mais especfica, os elementos de comutao, switches e roteadores,

Figura 3.2: Identificao dos fluxos OpenFlow pelo FlowVisor [20].

O FlowVisor se coloca entre os diversos elementos da rede. O comandos dos