Elton Gastardelli Kleis
Desenvolvimento de uma aplicação
para diferenciação de caminhos em redes
definidas por software
Niterói, 2 de dezembro de 2014
Elton Gastardelli Kleis
Desenvolvimento de uma aplicação
para diferenciação de caminhos em redes
definidas por software
Trabalho apresentado ao Curso de
Engenharia de Telecomunicações da
Universidade Federal Fluminense -
UFF, como requisito para obtenção
do título de Bacharel em Engenharia
de Telecomunicações.
Orientadora: Prof. Dra. Natalia
Castro Fernandes
Niterói, 2 de dezembro de 2014
Elton Gastardelli Kleis
Desenvolvimento de uma aplicação
para diferenciação de caminhos em redes
definidas por software
Trabalho apresentado ao Curso de
Engenharia de Telecomunicações da
Universidade Federal Fluminense -
UFF, como requisito para obtenção
do título de Bacharel em Engenharia
de Telecomunicações.
Aprovado em: 10 de Dezembro de 2014
Comissão julgadora:
Prof. Dr. Ricardo Campanha Carrano Prof. Dr. João Marcos Meirelles da Silva
Prof. Dra. Natalia Castro Fernandes
Niterói, 2 de dezembro de 2014
Agradecimentos
Primeiramente gostaria de agradecer à minha família, à meu pai Samuel, meu irmão
Natan e principalmente à minha mãe Sandra e ao meu avô Pedro (in memoriam) pelo
amor, carinho e por terem sempre me apoiado e acreditado no meu potencial. Gostaria de
agradecer também a minha namorada Patricia, que desde o ensino médio esteve ao meu lado,
comemorando comigo os bons momentos e me apoiando nos maus. Gostaria de agradecer
aos professores, Natalia Fernandes, Ricardo Carrano, Tadeu Nagashima, Gilberto Ferreira,
e a todos os outros que me ajudaram na busca do conhecimento. Agradeço também ao
professor Márcio Albuquerque (CBPF) por todo o apoio e conselhos e ao Luís Henrique
Rosati Rocha (BNDES) pelo exemplo de caráter e pro�ssionalismo. Agradeço a todos meus
amigos que direta ou indiretamente contribuíram para minha formação, principalmente ao
Alan Henrique Ferreira, Gabriel Oliveira e ao Rogério Libarino. A todos vocês, meu muito
obrigado!
Elton Gastardelli Kleis
i
Resumo
Nessa monogra�a, é apresentado um novo paradigma em redes de computadores, as redes
de�nidas por software.
Esse conceito surgiu em universidades americanas em meados de 2008 e propõe a retirada
da �inteligência� dos dispositivos de redes como switches e roteadores. Essa �inteligência�
seria concentrada em um controlador, entidade com total visão e controle da rede.
Em redes de�nidas por software, têm-se uma maior �exibilidade, já que se pode criar
diversas aplicações, programando o controlador da rede. Aplicações que hoje seriam impensá-
veis começarão a ser desenvolvidas com facilidade. Diante desse novo paradigma em redes de
computadores, uma aplicação simples desenvolvida em Python é apresentada. Essa aplicação
altera o caminho de um determinado �uxo mediante a uma circunstância pré-estabelecida.
A mesma foi testada utilizando o emulador Mininet e alguns resultados de desempenho
são apresentados.
Palavras-chave: SDN, Redes de�nidas por software, Redes programáveis, POX, Mininet.
ii
Abstract
In this monograph, a new computer networks' paradigm is presented, Software-De�ned
Networking.
This concept was born in American universities around 2008 proposing removal of the
�intelligence� in networks devices such as switches and routers. This �intelligence� would be
centralized in a controller, an entity with total view and control of the network. Due this
fact, Software-De�ne Networking is more �exible, considering the fact that it is possible to
create several applications, simply programming the network controller. Applications that
are unthinkable nowadays, would be developed easily.
Thinking about this new computer networks' paradigm, a simple application that was
developed in Python language is introduced on this monograph. This application consists
on changing the path of a speci�c data �ow according a pre-established condition.
The application was tested using Mininet emulator and the performance results will be
discussed on the present work.
Keywords: SDN, Software-De�ned Networking, Programmable Networks, POX, Mininet
iii
Lista de �guras
2.1 As quatro camadas do modelo TCP/IP. . . . . . . . . . . . . . . . . . . . . . 4
2.2 Em (a) tem-se a visão do usuário da rede e em (b) a estrutura física com os
enlaces e roteadores representados. . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Cabeçalho do protocolo IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Algoritmo executado pelo roteador ao receber um pacote . . . . . . . . . . . 10
2.5 Ilustração do aprendizado de rotas pelo roteador e distinção entre as bases de
informações de roteamento e de encaminhamento . . . . . . . . . . . . . . . 12
2.6 Em (a), tabela de encaminhamento presente no roteador � `Y�. (b) ilustra uma
mensagem de atualização do roteador �X� que irá causar mudanças em �Y� . 13
2.7 Troca de rótulos realizada por cada dispositivo . . . . . . . . . . . . . . . . . 15
3.1 Planos de controle e dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Con�guração básica SDN, com um controlador externo con�gurando o dispo-
sitivo de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Representação de uma rede genérica. . . . . . . . . . . . . . . . . . . . . . . 20
4.1 Switch OpenFlow idealizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Entrada da tabela de �uxos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Campos de cabeçalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Lista dos contadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Fluxograma do processamento dos pacotes. . . . . . . . . . . . . . . . . . . . 26
4.6 Tipos de mensagens para modi�cação da tabela de �uxos. . . . . . . . . . . 28
4.7 Componentes de um switch OpenFlow 1.1 . . . . . . . . . . . . . . . . . . . 29
4.8 Fluxograma detalhando o �uxo de pacotes através do switch OpenFlow 1.1 . 30
4.9 Alguns controladores OpenFlow existentes . . . . . . . . . . . . . . . . . . . 32
5.1 Topologia simples com dois hosts e um switch. . . . . . . . . . . . . . . . . . 33
5.2 Virtualização completa dos dispositivos. . . . . . . . . . . . . . . . . . . . . 34
5.3 Virtualização "leve"dos dispositivos. . . . . . . . . . . . . . . . . . . . . . . . 34
6.1 Pacotes LLDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Fluxograma representando primeira etapa da execução da aplicação. . . . . . 37
6.3 Pacotes ARP e respota do controlador. . . . . . . . . . . . . . . . . . . . . . 37
iv
LISTA DE FIGURAS v
6.4 Resposta do controlador para outros pacotes. . . . . . . . . . . . . . . . . . . 38
6.5 Fluxograma representando o evento de Packet-In. . . . . . . . . . . . . . . . 38
6.6 Fluxograma do teste de links e chaveamento entre caminhos. . . . . . . . . . 39
7.1 Topologia utilizada nos testes. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Inicialização do Mininet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.3 Inicialização da aplicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.4 Comandos do Iperf nos clientes. . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.5 Comandos do Iperf no servidor. . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.6 Percentual da perda de pacotes com os �uxos sendo enviados sempre por
caminhos diferentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.7 Teste com dois hosts enviando por caminhos diferentes. . . . . . . . . . . . . 43
7.8 Percentual da perda de pacotes com ambos os �uxos sendo enviados sempre
pelo melhor caminho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.9 Teste com dois hosts enviando pelo mesmo caminho. . . . . . . . . . . . . . 44
7.10 Percentual da perda dos pacotes, realizando a mudança de rota dinamicamente. 45
7.11 Resultado do primeiro teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.12 Tabela de �uxos do switch 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.13 Percentual médio dos erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.14 Taxa de transmissão média . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Lista de acrônimos
API - Application Programming Interface
ARP - Address Resolution Protocol
ARPANET - Advanced Research Projects Agency Network
AS - Autonomous System
ATM - Asynchronous Transfer Mode
BYOD - Bring Your Own Device
CBE - Content-Based Emulation
CIDR - Classless Inter-Domain Routing
CLI - Command Line Interface
EGP - Exterior Gateway Protocol
EIGRP - Enhanced Interior Gateway Routing Protocol
FIB - Forwarding information base
LSA - Link State Advertisement
LLDP - Link Layer Discovery Protocol
LSP - Link State Packet
IGP - Interior Gateway Protocol
IP - Internet Protocol
ISP - Internet Service Provider
MAC - Media Access Control
MPLS - Multiprotocol Label Switching
OSPF - Open Shortest Path First
ONF - Open Network Foundation
QoS - Quality of Service
RIB - Routing Information Base
RIP - Routing Information Protocol
SDN - Software-De�ned Networking
SSL - Secure Sockets Layer
TCP - Transmission Control Protocol
TLS - Transport Layer Security
ToS - Type of Service
UDP - User Datagram Protocol
VoIP - Voice over IP
vi
Sumário
Lista de �guras iv
1 Introdução 1
1.1 Motivação e objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Conceitos básicos das redes de computadores 4
2.1 Modelo em camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Endereçamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Máscara de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Encaminhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Protocolos do tipo vetor distância . . . . . . . . . . . . . . . . . . . . 12
2.4.2 Protocolos do tipo estado de enlace . . . . . . . . . . . . . . . . . . . 14
2.5 Comutação baseada em rótulos . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 Classi�cação de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 SDN - Redes De�nidas por Software 17
3.1 Engenharia de Tráfego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Um novo paradigma em redes de computadores . . . . . . . . . . . . . . . . 18
4 OpenFlow 22
4.1 Composição dos switches OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Tabela de �uxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 O canal seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Outras versões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1 OpenFlow 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 OpenFlow 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4.3 OpenFlow 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.4 OpenFlow 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 POX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Mininet 33
vii
SUMÁRIO viii
6 A aplicação desenvolvida 36
6.1 Executando a aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7 Simulação e resultados 40
7.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Conclusões 48
9 Apêndice A 50
9.1 Código para criação da topologia . . . . . . . . . . . . . . . . . . . . . . . . 50
10 Apêndice B 52
10.1 Código para calcular as rotas . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11 Apêndice C 56
11.1 Código da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Referências bibliográ�cas 66
Capítulo 1
Introdução
As redes de computadores nos permitem fazer coisas inimagináveis há poucas décadas.
Seu embrião teve início no �nal da década de 1960 com a então denominada ARPANET
(Advanced Research Projects Agency Network), que buscava interligar as bases militares e
os departamentos de pesquisa norte americanos. Muito evolui desde então. Modelos para
protocolos de comunicação foram criados e muitos protocolos foram desenvolvidos, sejam
para suprir a demanda de aplicações, sejam para calcular os caminhos que os pacotes devem
percorrer ao longo da rede.
Devido à essa evolução de ideias, desde o início das pesquisas sobre comutação de pacotes
e da ARPANET, juntamente com a evolução do hardware utilizado, hoje temos inúmeras
possibilidades na rede. Anexar enormes quantidades de arquivos em nossos e-mails, jogar
jogos com pessoas do mundo inteiro em tempo real, ou até mesmo realizar ligações telefônicas
através da Internet.
Entretanto, talvez hoje as redes estejam na iminência de uma mudança de paradigma,
mudança essa que possibilitará o desenvolvimento de aplicações cuja implementação com
a tecnologia atual seria impossível. Com a utilização de redes de�nidas por software (SDN
- Software-De�ned Networking), será possível um total controle da rede. Não haverá mais
a necessidade de hardwares especializados, mas sim, poderá se utilizar hardwares genéricos
programáveis. Novos protocolos poderão ser testados e implementados com uma rapidez
nunca antes vista e aplicações que hoje são impensáveis se tornarão absolutamente viáveis
através da implementação dessa tecnologia.
1
1.1 MOTIVAÇÃO E OBJETIVOS 2
1.1 Motivação e objetivos
Atualmente, as redes de computadores se tornaram parte essencial da infraestrutura
de nossa sociedade. Hoje, inúmeras aplicações �rodam� sobre a Internet, aplicações essas
que não foram imaginadas no projeto inicial das redes de computadores. Com o objetivo de
suportar o número crescente de aplicações e usuários, diversos �remendos� foram sendo feitos
ao longo dos anos. Entretanto, substancialmente, o núcleo da rede se manteve o mesmo. Os
softwares de switches e roteadores não podem ser reprogramados e novas ideias e protocolos
não podem ser testados em uma rede em produção, fato esse denominado por alguns autores
como �ossi�cação� da rede (McKeown et al. , 2008). Nesse cenário, surgem as redes de�nidas
por software.
O conceito de redes programáveis não é novo. Como exemplo, tem-se o conceito de redes
ativas na década de 1990 (Feamster et al. , 2014). Entretanto, pela primeira vez, o conceito
é amplamente difundido e aceito. As redes de�nidas por software vêm apresentando grande
aceitação por parte da comunidade acadêmica e pelos principais fabricantes de equipamentos,
que já começaram a desenvolver soluções voltadas para esse modelo.
Diante o exposto, como objetivo geral, essa monogra�a pretende apresentar ao leitor
esse novo paradigma em redes de computadores, mostrando o quão importante o mesmo
será para pesquisadores que necessitam testar novos protocolos assim como para gestores
que precisam gerenciar redes de computadores todos os dias.
Para tal, os seguintes objetivos especí�cos devem ser atingidos:
• Apresentação dos conceitos básicos das redes de computadores atuais, fornecendo um
conhecimento mínimo para aqueles que não estejam familiarizados com redes de com-
putadores;
• Abordar conceitos como plano de controle e de dados, e sua separação nas redes de�-
nidas por software;
• Apresentar conceitos do OpenFlow, implementação mais difundida das redes de�nidas
por software;
• Apresentação de uma aplicação programada em Python, para redes de�nidas por soft-
ware. Essa aplicação altera o caminho de um �uxo pré-estabelecido, mediante a uma
alta utilização da largura de banda do caminho principal;
1.2 ORGANIZAÇÃO DO TRABALHO 3
1.2 Organização do trabalho
Essa monogra�a está estruturada como mostrado a seguir.
No Capítulo 2, serão apresentados conceitos de redes de computadores básicos para que
seja possível o entendimento posterior das redes de�nidas por software. O mesmo tratará de
assuntos como o modelo de camadas TCP/IP, endereçamento, encaminhamento de pacotes
e comutação baseada em rótulos.
O Capítulo 3 tratará dos conceitos básicos sobre planos de controle e de dados e, sequen-
cialmente, da de�nição de redes de�nidas por software.
No Capítulo 4, será apresentado o padrão/protocolo OpenFlow. Os switches OpenFlow
serão de�nidos e suas características como tabela de �uxos e o canal seguro serão explana-
das. Também são apresentados nesse capítulo os principais controladores disponíveis, dando
enfoque ao POX, controlador utilizado.
O Mininet, emulador de redes utilizado nesse trabalho, é apresentado e suas caracterís-
ticas explicadas no Capítulo 5.
No Capítulo 6 uma descrição detalhada da aplicação desenvolvida será apresentada. Já
no Capítulo 7 são apresentados os resultados dos testes feitos, veri�cando como o uso da
aplicação reduziu a perda de pacotes.
As conclusões são apresentadas no Capítulo 8 e nos capítulos seguintes os códigos utili-
zados para o experimento podem ser encontrados.
Capítulo 2
Conceitos básicos das redes de
computadores
Nesse capítulo, serão abordados conceitos como modelo de camadas TCP/IP, endere-
çamento, encaminhamento e classi�cação de pacotes. Conceitos esses fundamentais para o
pleno entendimento das vantagens e desvantagens das redes de�nidas por software.
2.1 Modelo em camadas
As redes de computadores atuais, em sua maioria, seguem o modelo denominado TCP/IP
(Transmission Control Protocol / Internet Protocol). O modelo apresenta um conjunto de
protocolos para comunicação entre dispositivos. Esses protocolos são organizados de acordo
com uma pilha de camadas, onde cada camada irá oferecer serviços para as camadas superio-
res. Essa divisão em camadas, ao reduzir a complexidade, facilita a implementação de novas
tecnologias, permitindo também a interconectividade entre sistemas. A Figura 2.1 apresenta
o modelo TCP/IP de 4 camadas.
Figura 2.1: As quatro camadas do modelo TCP/IP.
4
2.1 MODELO EM CAMADAS 5
Na camada de aplicação, o nível mais alto do modelo, usuários utilizam programas que
acessam serviços disponíveis através da rede TCP/IP. A aplicação irá interagir com pro-
tocolos da camada de transporte para enviar e receber dados. Como será visto adiante, o
modelo foi concebido para que todas as outras camadas sejam transparentes para o usuário
�nal, ou seja, o mesmo não precisa ter conhecimento sobre a implementação das camadas
subjacentes.
A principal função da camada de transporte é prover uma comunicação ponto-a-ponto,
ou seja, conectando uma aplicação de um dispositivo origem com uma aplicação em um
dispositivo destino, independentemente da quantidade de equipamentos intermediários. Com
isso, a camada transporte deve aceitar dados provenientes de diversas aplicações, encapsulá-
los, incluindo informações que serão utilizadas para controle e para identi�cação da aplicação
de origem e destino e enviar esses dados encapsulados para as camadas mais baixas.
A camada de transporte pode também regular o �uxo de informações, podendo inclusive
oferecer um transporte con�ável, como por exemplo, veri�cando periodicamente a conexão
estabelecida e assegurando que os dados estão sendo enviados e recebidos corretamente,
chegando sem erros. São exemplos de protocolos dessa camada, o UDP (Datagram Protocol)
e o TCP.
A camada de internet lida com a comunicação de um dispositivo a outro, aceitando
pedidos de envio de pacotes da camada de transporte. A mesma irá encapsular os dados da
camada de transporte em um pacote IP, preenchendo o cabeçalho com diversas informações,
inclusive com o endereço lógico de origem (IP de origem) e o endereço lógico de destino (IP
de destino).
A camada de internet também é responsável por encaminhar esses pacotes para a camada
de acesso à rede, onde os mesmos serão encaminhados diretamente para o destino (podendo
vir a passar por dispositivos como switches e hubs), se os hosts estiverem na mesma rede.
Caso não estejam, como duas redes diferentes não se �enxergam� os pacotes devem ser
enviados para equipamentos que fazem a interligação entre redes, denominados roteadores.
Através dos roteadores os pacotes podem ser encaminhados por redes intermediárias, até
chegarem ao destino �nal. A camada de internet também é responsável por lidar com os
pacotes IP's recebidos, checando sua validade e veri�cando se os mesmos são destinados para
um host na rede local ou se devem ser encaminhados para outras redes. Maiores detalhes
sobre a camada de rede serão vistos na seção sobre encaminhamento.
A camada de acesso à rede de�ne as regras de acesso ao meio físico de�nindo o ende-
reçamento físico e os protocolos necessários para essa transmissão. Além disso, converte os
dados vindos da camada superior (internet) em sinais elétricos/ópticos, tornando possível a
transmissão em cabos e �bras ópticas.
É importante entender que para a camada de internet não importa a localização física das
máquinas, mas a localização lógica das redes. A camada de acesso à rede, é responsável pela
identi�cação de cada máquina (endereçamento físico) em uma rede local. O ARP (Address
Resolution Protocol), protocolo da camada de rede, fará a tradução do endereço lógico para
2.2 ENDEREÇAMENTO 6
o endereço físico, quando o pacote de dados já estiver na rede de destino.
Para �nalizar, as redes em camadas são projetadas de modo que uma determinada ca-
mada no destino receba exatamente os mesmos objetos enviados pela mesma camada cor-
respondente na origem, ou seja, os mesmos dados enviados pela camada de aplicação na
origem, devem ser os mesmos dados recebidos pela camada de aplicação no destino.
As redes de computadores em geral, sobretudo a Internet, foram projetadas para prover
uma interconexão universal entre computadores independentemente das particularidades da
rede aos quais estejam conectados, tornando-se transparente para o usuário, que a vê como
uma única rede virtual (como pode ser visto na Figura 2.2), a qual todas as máquinas estão
conectadas. Essa virtualização será importante para o entendimento das redes de�nidas por
software.
Figura 2.2: Em (a) tem-se a visão do usuário da rede e em (b) a estrutura física com os enlacese roteadores representados.
Fonte: Comer (2013)
2.2 Endereçamento
Sendo a camada de internet uma das mais importantes do modelo TCP/IP, torna-se
interessante o entendimento da divisão e endereçamento lógicos dos dispositivos, assim como
também é interessante entender como ocorre o roteamento e encaminhamento dos pacotes.
Em uma rede TCP/IP, cada adaptador de rede existente em um dispositivo é identi�cado
por um número chamado endereço IP. Tomando-se como base o IP versão 4, esse endereço IP
consiste em quatro conjuntos de 8 bits. Esses octetos, quando representados, são separados
por pontos.
2.2 ENDEREÇAMENTO 7
Um exemplo de endereço IP segue abaixo:
00001010.00000000.00000000.00000001
Dessa forma, todos os 32 bits são representados. Entretanto, a forma mais usual de
representação do endereço IP, é a decimal. O mesmo endereço IP representado acima, pode
ser escrito como:
10.0.0.1
Dito isso, pode-se concluir que o menor octeto possível é o 00000000 (0 em decimal) e o
maior octeto possível é o 11111111 (255 em decimal), ou seja, cada octeto pode variar de 0
a 255.
Parte do endereço IP será utilizada para representar a rede a qual o dispositivo está
conectado e a outra parte será utilizada para representar o dispositivo em si.
2.2.1 Máscara de rede
A máscara de rede é um recurso utilizado para segmentar redes logicamente. Com esse
recurso, pode-se ter várias redes lógicas diferentes disponíveis no mesmo espaço físico, ou
ainda, pode-se ter uma única rede lógica em mais de uma localidade física.
Essa rede lógica pode ser entendida como conjuntos independentes de dispositivos (com-
putadores, impressoras, switches) conectados à rede em um determinado espaço físico. As
divisões em redes lógicas diferentes são feitas justamente com base no endereço IP e na
máscara de rede.
A máscara de rede é de�nida como um conjunto de 32 bits divididos em quatro octetos,
assim como o endereço IP. Entretanto, algumas regras são levadas em consideração na criação
da máscara de rede Filho (2013):
• Não pode haver a mistura de algarismos 0 e 1;
• Não pode haver algarismo 0 antes de algarismo 1;
Segue abaixo um exemplo de máscara de rede, com os bits representados e também na
forma decimal:
11111111.00000000.00000000.00000000
255.0.0.0
Essa máscara de rede será comparada com o endereço IP. Os bits que forem 1 na máscara
de rede representam a porção da rede no endereço IP e os bits que forem 0 representam o
dispositivo.
Logo, pegando-se o endereço IP do exemplo acima e analisando-o com o exemplo de
máscara de rede, tem-se que os oito primeiros bits do endereço IP são referentes à rede, ou
seja, o valor �10�. Já os �.0.0.1� representam o dispositivo dessa rede.
A notação usual, a notação CIDR (Classless Inter-Domain Routing), é a representação
do endereço IP, seguido de uma barra (/) e da quantidade de bits que são correspondentes
à porção de rede.
2.3 ENCAMINHAMENTO 8
Logo, como foram utilizados oito bits para a máscara de rede acima, temos a seguinte
notação:
10.0.0.1/8
Um outro exemplo segue abaixo:
IP : 11000000.10101000.00000000.00000001 = 192.168.0.1
Máscara: 11111111.11111111.11111111.00000000 = 255.255.255.0
Notação CIDR: 192.168.0.1/24
Logo, os 24 primeiros bits representam a porção do IP destinado à rede e os últimos 8 bits
representam o dispositivo daquela rede. Para representar o endereço de rede, completa-se a
parte do endereço IP referente ao dispositivo com bits zero.
Logo para os dois exemplos apresentados têm-se as redes:
10.0.0.0/8
192.168.0.0/24
Os conceitos de máscaras de rede e de endereço de rede são importantes, pois os mesmos
serão utilizados nos roteadores para a realização do encaminhamento que será abordado a
seguir.
2.3 Encaminhamento
Para que o conceito de encaminhamento de pacotes em redes de computadores atuais
possa ser compreendido, é importante diferenciar-se os tipos de serviços que a camada de
internet pode oferecer.
A camada de internet oferece dois tipos distintos de serviços. O serviço orientado a
conexão e o serviço não orientado a conexão. As redes orientadas a conexões são denominadas
redes de circuitos virtuais. Como exemplos, têm-se as redes ATM (Asynchronous Transfer
Mode) e Frame Relay. Já a Internet é uma rede de datagramas, ou seja, uma rede não
orientada a conexões. Nesse trabalho, quando não especi�cado o contrário, o texto estará
tratando das redes não orientadas a conexões.
O serviço de entregas oferecido pela camada de rede em uma rede de datagramas, como
a Internet, pode ser de�nido como incerto, de melhor esforço (best-e�ort) e com entrega de
pacotes sem conexão.
O serviço é incerto, pois a entrega de pacotes não é garantida. Os pacotes podem ser
perdidos, duplicados, podem chegar atrasados ou até mesmo fora de ordem. O serviço é dito
de melhor esforço, porque os pacotes tentarão ser entregues, entretanto não há garantias.
Não há garantia de largura de banda e nem mesmo indicações de congestionamento.
Finalmente o serviço também é de�nido como sem conexão, pois cada pacote é tratado
independentemente. Uma sequência de pacotes enviados de um dispositivo a outro, podem
trafegar por diferentes caminhos. Não existe um circuito pré-de�nido como existe, por exem-
plo, nas redes de circuitos virtuais. Uma exceção seria a tecnologia MPLS (Multiprotocol Label
2.3 ENCAMINHAMENTO 9
Switching) que será abordada posteriormente.
O protocolo IP, um dos mais importantes do modelo TCP/IP, apresenta todas as carac-
terísticas supracitadas e ainda:
• De�ne a unidade básica de dados que será transmitida através da rede TCP/IP, espe-
ci�cando o formato dos pacotes utilizados por todos os dados.
• O IP de�ne uma série de regras, como por exemplo, como dispositivos e roteadores de-
vem processar os pacotes e as condições sob as quais os pacotes podem ser descartados.
Comer (2013)
Apenas a título de ilustração, segue na Figura 2.3 o formato do cabeçalho IPv4.
Figura 2.3: Cabeçalho do protocolo IPv4
Fonte: RFC 791
Conforme dito anteriormente, a transmissão de datagramas IP entre dois dispositivos em
uma única rede física, não envolverá o uso de roteadores. O dispositivo que está enviando
os dados encapsulará o datagrama em um quadro, vinculará o endereço do próximo salto ao
endereço físico do dispositivo de destino e enviará o quadro resultante para o dispositivo de
próximo salto.
Caso o dispositivo não esteja na mesma rede, o protocolo selecionará o próximo roteador
para onde o pacote deve ser enviado. Esse processo se repete até que o pacote chegue a um
roteador que possa entregar o pacote diretamente para o dispositivo de destino.
Com o objetivo de descobrir se o dispositivo de destino se encontra conectado em uma
de suas redes, o roteador realiza um teste simples. Como foi visto, o endereço IP é dividido
em duas partes, uma que irá identi�car a rede e outra que irá identi�car o dispositivo.
Logo, ao receber o quadro, o roteador desencapsula o pacote e compara os bits referentes
à identi�cação da rede do endereço IP do dispositivo destino com o endereço de rede dos
endereços IP's de suas interfaces. Uma equivalência signi�ca que o dispositivo destino se
encontra na rede ligada a essa interface. Esse teste é computacionalmente e�ciente, pois
requer apenas algumas instruções de máquina.
O encaminhamento dos pacotes é do tipo próximo salto, ou seja, o roteador que acabou
de receber o pacote, não precisa saber quais são todos os saltos intermediários que o pacote
2.3 ENCAMINHAMENTO 10
deverá percorrer até chegar ao destino. Precisa saber apenas qual é o próximo salto, e para
isso, o mesmo irá veri�car sua tabela de encaminhamento (FIB - Forwarding information
base).
Se todos os roteadores da internet precisassem ter em suas tabelas de encaminhamento
todos os IP's disponíveis, os mesmo precisariam de uma enorme quantidade de memória além
de que, a cada alteração de rota os roteadores precisariam reescrever inúmeras entradas.
Entretanto, as tabelas de encaminhamento precisam conter apenas o endereço das redes, ou
seja, o pre�xo das redes dos endereços IP.
Então, uma tabela de encaminhamento terá, conceitualmente, um conjunto de pares
(P,R) onde �P� é o pre�xo da rede e �R�, é o endereço IP do próximo roteador para onde os
dados devem ser enviados com o objetivo de chegarem a rede �P�.
Pode-se pensar que o protocolo de roteamento, software que preencherá as informações na
FIB, escolherá as melhores rotas de acordo com a utilização corrente do link, pelo tamanho
do datagrama, tipo de dados que estão sendo transportados ou ainda de acordo com o
custo dos links. Entretanto, será visto que a maioria dos protocolos de roteamento são bem
menos so�sticados, selecionando rotas baseadas em dados �xos sobre menores caminhos.
Fato que é interessante ressaltar, já que nas redes de�nidas por software, novos protocolos de
roteamento com as mais diversas métricas poderão ser implementados facilmente, tornando
o encaminhamento mais inteligente e robusto.
Voltando-se ao encaminhamento de pacotes, o algoritmo realizado pelo roteador ao re-
ceber um pacote pode ser resumido na Figura 2.4.
Figura 2.4: Algoritmo executado pelo roteador ao receber um pacote
Fonte: Algoritmo baseado em Comer (2013)
2.4 ROTEAMENTO 11
Entretanto, para o algoritmo acima funcionar corretamente, algumas condições precisam
ser pré-de�nidas.
Primeiramente, diferentemente do modelo conceitual de tabelas de encaminhamento, a
tabela precisa conter o IP da sub-rede de destino que será comparado, a máscara de rede, o
IP do próximo roteador e a interface para onde devem ser enviados os pacotes. A interface
também é importante, pois como um roteador pode estar conectado a duas ou mais redes, o
mesmo precisa saber por qual interface deve enviar os frames. Em segundo, as entradas na
tabela de encaminhamento precisam ser organizadas de forma decrescente, ou seja, as rotas
que apresentarem uma máscara de rede maior (rotas mais especí�cas) devem ser veri�cadas
antes das rotas mais genéricas. Comer (2013)
O encaminhamento, como foi visto, é uma das principais funções do protocolo IP e dos
roteadores. O mesmo não poderia atualmente ser executado corretamente, se não existissem
os protocolos de roteamento. Como será visto a seguir, as entradas na tabela de enca-
minhamento poderiam até ser con�guradas manualmente, mas essa ação com as redes de
computadores atuais, principalmente a Internet, se tornaria impraticável.
2.4 Roteamento
Na seção anterior, foi visto o encaminhamento desempenhado pelo IP, onde dado um
determinado pacote IP, é feita a veri�cação do próximo salto na tabela de encaminhamento
e o direcionamento desse pacote para o mesmo.
As rotas da tabela de encaminhamento podem ser originadas basicamente de três formas.
A primeira são as rotas diretas. São as redes as quais o roteador se conecta diretamente. A
segunda é a forma estática, onde o gestor da rede precisa con�gurar cada rota manualmente.
Pode ser utilizada em pequenas redes domésticas, entretanto em redes mais complexas, onde
existirão diversos roteadores organizados em uma malha, existindo diversos enlaces entre eles,
essa con�guração manual torna-se muito onerosa. A con�guração das rotas manualmente
também torna-se um problema devido à necessidade de reagir dinamicamente às mudanças
da rede, como por exemplo devido à falhas de um enlace ou ainda quando novos roteadores
são acrescentados.
Já na terceira forma, chamada de roteamento dinâmico, as rotas serão con�guradas
automaticamente, de acordo com os protocolos de roteamento e como será visto, existem
basicamente dois tipos predominantes, os protocolos do tipo vetor distância e do tipo estado
de enlace.
Antes de veri�car-se o roteamento dinâmico, torna-se interessante a distinção de pro-
tocolos IGP (Interior Gateway Protocol) e EGP (Exterior Gateway Protocol). A Internet,
como é sabido, é uma rede de redes de computadores. Cada agrupamento organizacional
é de�nido como um sistema autônomo (AS - Autonomous System), sistema esse que pode
operar isoladamente de todos os outros agrupamentos. Logo, nem todas as informações de
2.4 ROTEAMENTO 12
roteamento que são trafegadas internamente dentro de um AS devem ser compartilhadas com
outros AS's, já que não é interessante a divulgação de detalhes internos do mesmo. Com isso,
têm-se os protocolos que distribuem informações de roteamento dentro dos AS's, chamados
de IGP's e os protocolos EGP's, protocolos de roteamento que distribuem informações entre
AS's. Farrel (2004)
A Figura 2.5 ilustra o aprendizado das rotas pelo rotador.
Figura 2.5: Ilustração do aprendizado de rotas pelo roteador e distinção entre as bases de infor-mações de roteamento e de encaminhamento
Fonte: Farrel (2004)
As rotas provenientes a partir dos protocolos de roteamento são combinadas com as rotas
estáticas con�guradas e com as rotas diretas descobertas, dando origem a RIB (Routing
Information Base).
A RIB apresenta diversas informações sobre as rotas disponíveis na rede. Parte dessa
informação pode sugerir várias rotas para um único destino, e um mecanismo de decisão de
roteamento aplica políticas de roteamento para determinar as melhores rotas. A RIB dará
origem a FIB. A FIB oferece informações não ambíguas ao componente do roteador que
encaminha os pacotes de dados.
2.4.1 Protocolos do tipo vetor distância
A ideia dos protocolos dessa modalidade é bastante simples. Cada roteador mantém uma
lista de todos os destinos alcançáveis da rede e distribui essa lista de tempos em tempos
para seus vizinhos.
2.4 ROTEAMENTO 13
Cada entrada na tabela de roteamento identi�cará a rede de destino, o roteador usado
para o próximo salto e a �distância� até a rede de destino. Essa distância geralmente será
a quantidade de saltos (hops) até o destino. Por exemplo, uma rede diretamente conectada
estará a zero saltos de distância. Se um datagrama precisa passar por �N� roteadores para
chegar ao destino, o destino está a �N� saltos de distância.
Quando um roteador novo �X� é inserido, primeiramente ele irá se anunciar aos vizinhos.
Os vizinhos propagarão a informação dizendo que podem chegar até �X� com um salto de
distância e assim sucessivamente.
Quando uma mensagem, por exemplo, proveniente de �X�, chega em �Y�, �Y� tomará as
seguintes ações:
Se �X� conhece um destino que �Y� não, �Y� irá adicionar esse destino a sua tabela de
roteamento, con�gurando como próximo salto �X� e somando 1 ao custo para se chegar a
determinado destino;
Se �X� conhece um caminho mais curto para o destino, �Y� substitui a entrada em sua
tabela de roteamento, con�gurando o próximo salto para �X� e corrigindo o custo;
Se a entrada para um determinado destino já existe em �Y�, sendo o próximo salto para
a mesma, �X� e �X� anuncia um valor de custo diferente ao anterior, �Y� irá atualizar sua
tabela, corrigindo o custo;
Exemplo de tabela de encaminhamento pode ser visto na Figura 2.6.
Figura 2.6: Em (a), tabela de encaminhamento presente no roteador �`Y�. (b) ilustra uma mensa-gem de atualização do roteador �X� que irá causar mudanças em �Y�
Fonte: Imagem baseada em Comer (2013)
Essa modalidade de protocolos, torna-se ideal para redes pequenas a médias, uma vez
que a transmissão de toda a tabela de roteamento para cada vizinho é lenta e a ocorrência de
perdas pode causar loops, demandando um longo tempo para a convergência das informações.
Como vantagens, têm-se a baixa complexidade de implementação e os baixos requisitos de
processamento e memória.
Como exemplos de protocolos do tipo vetor distância, têm-se os protocolos RIP (Routing
Information Protocol) e EIGRP (Enhanced Interior Gateway Routing Protocol).
2.5 ROTEAMENTO 14
2.4.2 Protocolos do tipo estado de enlace
Diferentemente dos protocolos do tipo vetor distância, os protocolos do tipo estado de
enlace não irão distribuir uma lista de rotas, informando os custos e os destinos que o mesmo
pode atingir.
Os roteadores �carão, periodicamente, testando os status das conexões com seus vizi-
nhos, realizando a troca de pequenas mensagens para constatar se o vizinho está ativo e é
atingível. Caso o vizinho responda a mensagem, o link estará up, caso negativo, o mesmo
será considerado down.
Após a descoberta dos vizinhos, o roteador envia periodicamente mensagens para infor-
mar aos outros roteadores da rede sobre os status de cada um de seus links (mensagens
LSP - Link State Packet - ou LSA - Link State Advertisement - de acordo o protocolo). É
importante enfatizar que essas mensagens de status não especi�cam rotas, informam apenas
se a comunicação é possível entre o par de roteadores referidos na mensagem.
Esse processo de inundação das mensagens é simples. O roteador recebe um LSP e veri�ca
em seu banco de dados de estado de enlace se já conhece o enlace referido na mensagem.
Se conhecer, ele descartará o LSP, mas caso não conheça, ele acrescentará o enlace ao seu
banco de dados e enviará o novo LSP em cada uma de suas interfaces, exceto a interface em
que a mensagem foi recebida originalmente.
Logo, após a rede convergir, cada roteador possuirá um mapa completo e idêntico da
rede.
Para calcular as rotas entre os enlaces disponíveis na rede, os roteadores executam o
algoritmo de Dijkstra, algoritmo esse que irá calcular o melhor caminho entre o roteador
local e todos os outros destinos.
Um dos protocolos de estado de enlace mais conhecidos, o OSPF (Open Shortest Path
First), têm uma métrica padrão proporcional à largura de banda dos enlaces. Com isso,
o melhor caminho sempre será o mais rápido, ao contrário do vetor distância, que usa o
caminho com menor número de saltos.
Uma outra vantagem dos protocolos de estado de enlace é que cada roteador realiza
os cálculos das rotas independentemente, usando os mesmos dados de status originais, não
dependendo de roteadores intermediários como o vetor distância. Esse tipo de protocolo
é ideal para redes grandes, pois sua percepção de problemas ou de novos roteadores e a
consequente propagação dessas informações são rápidas. Mas, como desvantagem, o cálculo
das alterações nas tabelas de roteamento exige bastante processamento.
São exemplos de protocolos o OSPF e o IS-IS.
Nessa seção, termina-se uma breve introdução ao funcionamento das redes de compu-
tadores atuais. A próxima seção, tem como objetivo apresentar a comutação baseada em
rótulos, que será a base da tecnologia MPLS. Devido à �exibilidade de roteamento existente
em tal tecnologia, torna-se interessante a citação da mesma, para posterior compreensão das
redes de�nidas por software.
2.5 COMUTAÇÃO BASEADA EM RÓTULOS 15
2.5 Comutação baseada em rótulos
A comutação baseada em rótulos é o processo de encaminhar pacotes de dados dentro
da rede, baseado em algum rótulo associado com cada pacote. Essa ideia surgiu em meados
da década de 1980, com o objetivo de melhorar o desempenho na transmissão de pacotes.
A tecnologia nos comutadores explora o indexamento para atingir velocidades extrema-
mente altas no encaminhamento de dados. Para isso, cada pacote carrega um número inteiro
conhecido como rótulo. Quando um pacote chega no comutador, o comutador extrai o rótulo
e usa o valor como índice na tabela que irá especi�car a ação apropriada. Cada comutador
pode ter uma série de interfaces de saída e a ação geralmente consiste em enviar o pacote
por uma dessas interfaces.
A comutação baseada em rótulos, apresenta como grande vantagem a �exibilidade em
roteamento. Nem sempre é desejável que todos os dados para um mesmo destino sejam rote-
ados pelo mesmo caminho. Pode ser desejado que um tráfego de maior prioridade percorra
um caminho mais curto, enquanto que os tráfegos de menor prioridade, podem ser enviados
por caminhos mais longos. A maioria das técnicas de roteamento como foi visto, costuma
enviar o tráfego para o caminho mais curto.
Como citado, comutação de rótulos consiste em associar um rótulo pequeno e de formato
�xo em cada pacote de dados de modo que ele possa ser encaminhado na rede. Isso signi�ca
que cada pacote, precisa transportar um identi�cador que irá dizer aos nós da rede como
encaminhá-lo. Em cada salto por meio da rede, o pacote é encaminhado com base no valor
do rótulo que chega e é encaminhado com um novo valor de rótulo. A Figura 2.7 ilustra essa
troca de rótulos e o encaminhamento dos pacotes.
Figura 2.7: Troca de rótulos realizada por cada dispositivo
Fonte: Comer (2013)
Até o momento, a comutação baseada em rótulos foi descrita como uma tecnologia de
rede orientada para conexões de propósito geral. Será apresentado agora, como a comuta-
ção baseada em rótulos pode ser combinada com a Internet. Em 1991, a IETF (Internet
Engineering Task Force) padronizou através da RFC 3031 o MPLS.
2.5 COMUTAÇÃO BASEADA EM RÓTULOS 16
O protocolo utiliza a comutação baseada em rótulos, explicada anteriormente e como o
próprio nome sugere, o mesmo foi projetado para transportar quaisquer payloads. Na prática,
o MPLS é usado quase que exclusivamente para transportar pacotes IP.
Geralmente o MPLS é utilizado no núcleo de grandes ISP's (Internet Service Providers).
Roteadores na borda da rede do ISP irão examinar cada datagrama e decidir se utilizará
algum caminho da rede MPLS para encaminhar os dados ou se lidará com o datagrama com
o encaminhamento convencional.
O MPLS permite ao ISP oferecer serviços especiais para clientes individuais. Por exemplo,
considere uma grande empresa com escritórios no Rio de Janeiro e em Porto Alegre. Supondo
que a empresa deseje uma conexão segura entre essas duas localidades com performances
garantidas, o ISP pode estabelecer um caminho na rede MPLS entre esses dois escritórios e
pode con�gurar os roteadores ao longo do caminho para garantir o desempenho contratado.
2.5.1 Classi�cação de pacotes
Como citado anteriormente, o MPLS por utilizar comutação por rótulos, permite uma
maior �exibilidade no roteamento. Isso quer dizer que, em muitos casos, gerentes de redes
usam protocolos da camada de transporte para escolherem quais caminhos determinados
�uxos de dados devem seguir dentro da rede MPLS. Por exemplo, pode existir uma regra
que especi�que que todo tráfego web percorra um determinado caminho diferente dos outros
tráfegos.
Com isso, o modelo de camadas tradicional apresentado na seção �Modelo em camadas� é
insu�ciente para a tarefa de seleção de caminhos na rede MPLS, já que no modelo tradicional
os datagramas em trânsito não são desencapsulados até a camada de transporte.
Logo, se faz necessário de�nir a classi�cação de tráfego. Um sistema de classi�cação difere
do desencapsulamento devido à habilidade de atravessar as camadas.
Para entender a classi�cação de tráfego, imagine um pacote que foi recebido no roteador
e colocado na memória. Pensando no pacote como um array de bytes, para saber se um
determinado pacote corresponde a um tráfego web, basta veri�car alguns bytes. Como por
exemplo, veri�car os bytes correspondentes ao Ethernet type, para saber se é um pacote
IP, veri�car os bytes correspondentes ao campo protocolo, no pacote IP, para saber se o
protocolo utilizado é o TCP e veri�car os bytes correspondentes a porta de destino, para
veri�car se os mesmos correspondem à porta 80. Comer (2013)
Observe que todas as ações representam pesquisas no array de bytes. O sistema de
classi�cação não precisa entender nenhum dos cabeçalhos dos protocolos ou o signi�cado
dos bytes.
Na prática, o mecanismo de classi�cação geralmente utiliza uma série de regras de clas-
si�cação e as aplica até que uma correspondência é encontrada. Por exemplo, um gerente
pode especi�car algumas regras como: enviar todo tráfego web pelo caminho MPLS 1, enviar
todo tráfego RTP pelo caminho MPLS 2 e enviar todo tráfego VPN pelo caminho MPLS 3.
Capítulo 3
SDN - Redes De�nidas por Software
As redes de computadores atuais são compostas de inúmeros dispositivos diferentes como
roteadores, switches e hosts que implementam diversos protocolos complexos. Conforme as
mesmas foram crescendo e se tornando parte essencial da infraestrutura de nossa sociedade,
tornou-se árdua a tarefa de testar e implementar novos protocolos.
Com esse cenário em mente, a ideia de redes programáveis foi proposta com o objetivo
de facilitar futuras evoluções nas redes de computadores. Nesse capítulo, serão apresentados
os conceitos fundamentais das redes de�nidas por software, uma forma de programar a rede
que vem se destacando consideravelmente nos últimos anos.
É um novo paradigma que tem como objetivo facilitar substancialmente a gerência de
redes e permitir inovações e evoluções que o nosso modelo �ossi�cado� atual não permite
Nunes et al. (2014).
3.1 Engenharia de Tráfego
O modelo básico de encaminhamento de pacotes consiste em encaminhar o tráfego com
um dado endereço IP de destino por um caminho pré-estabelecido pelos protocolos de rote-
amento. Independente das outras características dos pacotes, como endereço IP de origem,
portas TCP/UDP ou ToS, todo o tráfego para um determinado endereço IP de destino, ao
chegar em um dado roteador, será encaminhado pela mesma interface.
Isso exposto, surge a necessidade de realizar uma engenharia de tráfego, ou seja, realizar
uma maior distinção entre os diferentes pacotes e, consequentemente, priorizar alguns em
detrimento de outros, com o objetivo de otimizar o desempenho da rede. Hoje, existem
tecnologias que realizam uma distinção e oferecem ao usuário �nal garantias de qualidade
de serviço, como por exemplo, as já citadas redes MPLS. Nas mesmas, através da criação
de circuitos virtuais e da comutação baseada em rótulos, pacotes com um mesmo endereço
IP de destino podem percorrer caminhos diferentes dentro de uma mesma rede.
Como será visto, implementando o paradigma de redes de�nidas por software, haverá um
salto na engenharia de tráfego, já que cada �uxo, ou seja, conjunto de pacotes de dados com
17
3.2 UM NOVO PARADIGMA EM REDES DE COMPUTADORES 18
algumas características em comum, poderá ser tratado individualmente e novos softwares
e formas de encaminhar esses �uxos poderão ser desenvolvidos e implementados de acordo
com as necessidades do gestor da rede.
3.2 Um novo paradigma em redes de computadores
Conceitualmente, um dispositivo de rede, como um roteador ou um switch, pode ser
dividido internamente em dois planos: o plano de controle e o plano de dados.
O plano de controle é a parte responsável pela �inteligência� do dispositivo. Por exemplo,
é o plano de controle que executa os códigos dos protocolos de roteamento, responsável pela
realização do cálculo das rotas em roteadores. Já o plano de dados é responsável por lidar
com os pacotes entrantes no dispositivo, veri�cando na tabela de encaminhamento por qual
interface o mesmo deverá ser encaminhado.
Atualmente, os dispositivos convencionais apresentam uma estreita ligação entre esses
planos. Essa interligação torna árdua a depuração de con�gurações e o controle do compor-
tamento de roteadores e switches Feamster et al. (2014).
A Figura 3.1 ilustra ambos os planos de controle e de dados:
Figura 3.1: Planos de controle e dados.
Fonte: Comer (2013)
O conceito base das redes de�nidas por software consiste em separar o plano de controle
do plano de dados e retirá-lo dos dispositivos. Com isso, a rede será formada por dispositivos
�burros� encaminhadores de pacotes e por uma camada de software programável onde haverá
um controlador de rede que coordenará todas as ações dos dispositivos. Esses dispositivos
encaminhadores de pacotes serão programados através de uma interface aberta, como, por
exemplo, a interface de�nida pelo OpenFlow, que será visto no próximo capítulo.
Atualmente, encontram-se no mercado switches OpenFlow (nomenclatura dada aos dis-
positivos �burros�) tanto puros quanto híbridos. Os puros, não apresentam nenhum plano de
3.2 UM NOVO PARADIGMA EM REDES DE COMPUTADORES 19
controle, con�ando completamente no controlador para lhe dizer como encaminhar os paco-
tes. Já os híbridos, suportam comandos do controlador em adição às operações e protocolos
atuais Nunes et al. (2014).
A Figura 3.2 ilustra a comunicação do controlador externo com o dispositivo de rede.
Figura 3.2: Con�guração básica SDN, com um controlador externo con�gurando o dispositivo derede.
Fonte: Comer (2013)
Vale salientar que as redes de�nidas por software suportam tanto controladores externos
totalmente centralizados, ou seja, apenas um controlador com visão total da rede, quanto
distribuídos, onde há alguns controladores controlando a rede (mesmo que de forma lógica
aparentem ser apenas um).
Na imagem 3.3, segue uma representação de dispositivos de redes genéricos, com um
sistema operacional externo conhecedor de toda a topologia rodando no controlador e pro-
gramas de controle diversos, sejam novos ou já em uso, como por exemplo, protocolos de
roteamento como OSPF e RIP.
Por ser um novo modelo, existem benefícios e desa�os/desvantagens com a sua imple-
mentação. Seguem abaixo alguns benefícios:
• Visualização uni�cada da rede - Com as redes de�nidas por software, passa-se a ter
uma visão global de toda a rede através do controlador, simpli�cando con�gurações e
gerência dos dispositivos.
• Recuperação mais rápida das falhas - Devido ao controle global, seja a falha em um
link ou em um nó da rede, a rede se reorganizará e convergirá mais rapidamente para
3.2 UM NOVO PARADIGMA EM REDES DE COMPUTADORES 20
Figura 3.3: Representação de uma rede genérica.
Fonte: McKeown (2011)
uma nova ótima con�guração, devido a utilização de algoritmos centralizados ao invés
de algoritmos distribuídos.
• Upgrade e implementação de novas aplicações - Uma das maiores vantagens desse novo
paradigma é a implementação de novas aplicações para a rede. Novos protocolos e novas
formas de encaminhar os dados poderão ser testadas e implementadas rapidamente,
pois não dependem mais de modi�cações no �rmware do switch ou do roteador. Além
disso, o controlador pode ter seu software atualizado e alterado sem haver perda de
pacotes em uma rede em produção.
Alguns desa�os/desvantagens encontrados são:
• Segurança - Uma das maiores dúvidas e preocupações são a respeito da segurança.
Retirando a �inteligência� dos dispositivos e levando-a para um controlador externo,
passaria-se a ter apenas um ponto crítico, onde caso seja violado, toda a rede sob esse
controlador estaria vulnerável. Essas preocupações se tornam ainda mais evidentes
em empresas que já adotam o conceito de BYOD (Bring Your Own Device) onde os
colaboradores da empresa levam para o ambiente de trabalho seus próprios aparelhos
eletrônicos. Aliando esse conceito com uma rede programável (onde inclusive vírus
poderão ser programados com o objetivo de prejudicar o desempenho e comprometer
a rede), os gestores terão uma preocupação a mais, já que qualquer dispositivo pode
estar contaminado com um software malicioso ao se conectar na rede.
• Conceito novo - As redes de�nidas por software assim como sua implementação mais
difundida, o OpenFlow, ainda se encontram imaturos. Muitos aspectos ainda precisam
ser amadurecidos e novas padronizações realizadas. Como exemplo, qual o nível de
3.2 UM NOVO PARADIGMA EM REDES DE COMPUTADORES 21
dependência os dispositivos genéricos devem ter dos controladores? Os mesmos devem
ser totalmente dependentes ou apenas parcialmente? Ou ainda, como os controladores
devem ser implementados? Como deve ser realizada a distribuição e separação de
domínios de cada controlador?
Com a retirada do plano de controle dos dispositivos, pode-se modelar e moldar dinâmi-
camente a rede, de acordo com a necessidade do gestor, permitindo que a gerência da rede
seja feita de forma muito mais fácil e e�ciente.
Atualmente, as limitações de largura de banda para cada tipo de serviço são uma re-
alidade, nos permitindo priorizar tráfego VoIP por exemplo, sobre outras aplicações. En-
tretanto, ao longo do dia, as necessidades dos usuários da rede podem ser alteradas e pos-
sivelmente uma determinada aplicação pode vir a ter uma prioridade maior que um tráfego
VoIP.
Com redes de�nidas por software, em tempo real, pode-se haver essa troca de prioridades
e a determinada aplicação prioritária passa rapidamente a trafegar com alta prioridade.
Todo esse modelamento do tráfego poderá ser feito através de um console de gerência, e
em instantes, os dispositivos da rede seriam con�gurados, não havendo mais a necessidade
de conectar-se a cada dispositivo.
Um exemplo similar pode ser visto no webinar da Cisco (Yamamoto e Scharra , 2014),
onde, num primeiro momento, um streaming de vídeo não era executado corretamente devido
a baixa prioridade e saturação do link principal. Após rápidos ajustes no controlador, o link
secundário (redundância) que antes estava ocioso, passou a ser utilizado e o streaming foi
feito corretamente.
Outro exemplo de implementação foi apresentado pelo Google em 2012 na Open Network
Summit (conferência destinada a discussões sobre SDN), onde o mesmo implementou uma
solução OpenFlow/SDN no backbone que trafega os dados entre seus datacenters Google
(2012).
Como visto, as redes de�nidas por software já são uma realidade, mesmo que ainda de
forma tímida. Muito precisa ser evoluído e amadurecido. Questões relativas à segurança
precisam ser devidamente estudadas e analisadas. Mas a liberdade proporcionada por esse
modelo não deixa dúvidas de que num futuro próximo as redes serão muito mais dinâmicas
e programáveis que as atuais, seja utilizando o paradigma SDN ou algum outro que venha
a ser derivado do mesmo.
Capítulo 4
OpenFlow
Após a de�nição do conceito das redes de�nidas por software, vista no capítulo anterior,
algumas dúvidas podem vir a surgir como:
• Como se dará a comunicação entre o controlador e os dispositivos de rede genéricos?
• Quais con�gurações e controle um determinado dispositivo deve oferecer?
• Qual deve ser o formato das mensagens enviadas pelo controlador?
As respostas para tais perguntas podem ser encontradas na implementação mais difun-
dida das redes de�nidas por software, o padrão OpenFlow.
Criado originalmente na universidade de Stanford, o OpenFlow é um padrão aberto,
que surgiu da necessidade dos pesquisadores executarem protocolos experimentais na rede
acadêmica.
É uma tecnologia proposta para padronizar a forma como o controlador se comunica com
os dispositivos de rede em uma arquitetura SDN, de�nindo também um protocolo para essa
comunicação. Dessa forma, o OpenFlow provê meios de controlar os dispositivos de rede
(switches OpenFlow) sem a necessidade dos fabricantes exporem o código de seus produtos.
Lara et al. (2014)
Assim, através do protocolo OpenFlow, os controladores podem programar as tabelas de
�uxo dos switches. Como será visto abaixo, a tabela de �uxos é parte essencial dos switches
OpenFlow.
Diferentes versões do protocolo OpenFlow estão disponíveis. A primeira versão foi a 0.2.0
lançada em Maio de 2008 e atualmente está obsoleta. A versão 1.0.0 lançada em Dezembro
de 2009 foi a mais amplamente divulgada e implementada, com isso a mesma terá um
foco maior nesse trabalho. Após a versão 1.0.0, foram lançadas as versões 1.1, 1.2, e 1.3 e
1.4 Lara et al. (2014).
O OpenFlow encontra-se em constante evolução e o mesmo é mantido pela ONF (Open
Network Foundation).
22
4.1 COMPOSIÇÃO DOS SWITCHES OPENFLOW 23
4.1 Composição dos switches OpenFlow
Baseando-se na versão 1.0.0, a versão mais difundida do OpenFlow, os switches OpenFlow
devem possuir/suportar as seguintes características McKeown et al. (2008):
• Tabela de Fluxos
• Canal Seguro
• Protocolo OpenFlow
A tabela de �uxos contêm 12 campos que serão utilizados para a classi�cação de um
�uxo, uma ação para cada �uxo e contadores.
O canal seguro irá conectar o switch OpenFlow ao controlador e permitirá que os co-
mandos passem por ele.
Já o protocolo OpenFlow é o que será utilizado para essa comunicação.
A Figura 4.1 ilustra as características citadas acima.
Figura 4.1: Switch OpenFlow idealizado.
Fonte: McKeown et al. (2008)
O switch OpenFlow deve ser capaz de realizar três simples ações com os �uxos entrantes:
• Encaminhar o �uxo entrante para uma determinada interface de saída, caso haja uma
entrada equivalente para o �uxo em questão em sua tabela de �uxos;
• Caso não haja entrada equivalente na tabela de �uxos, o switch deve ser capaz de
encapsular o primeiro pacote (ou todos, de acordo com a necessidade) e encaminhá-lo
para o controlador através do canal seguro. O controlador que irá decidir o que fazer
4.2 TABELA DE FLUXOS 24
com esse pacote. Inclusive, decidirá se uma entrada na tabela de �uxos do switch será
adicionada ou não;
• Por último, o switch OpenFlow também deve ser capaz de descartar pacotes;
4.2 Tabela de �uxos
Como dito anteriomente, a tabela de �uxos é parte essencial da caracterização de um
switch OpenFlow. Pode ser observado na Figura 4.2 que uma entrada na tabela de �uxos é
composta por:
Figura 4.2: Entrada da tabela de �uxos.
Fonte: Foundation (2009)
Os campos de cabeçalho são os campos que serão comparados com o �uxo entrante no
switch OpenFlow. A Figura 4.3, apresenta os campos de�nidos na versão 1.0.0:
Figura 4.3: Campos de cabeçalho.
Fonte: Foundation (2009)
Cada campo do cabeçalho pode ser ou não de�nido. Por exemplo, para o switch OpenFlow
funcionar como um roteador, basta especi�car o campo IP de destino.
Quanto aos contadores existem quatro tipos diferentes: Os contadores por tabela, por
�uxo, por porta e por �la. Os mesmos serão incrementados sempre que �uxos correspondentes
às entradas na tabela entrem no switch e serão utilizados em mensagens de estatísticas,
também de�nidas pelo OpenFlow.
A Figura 4.4 apresenta os contadores disponíveis:
4.2 TABELA DE FLUXOS 25
Figura 4.4: Lista dos contadores.
Fonte: Foundation (2009)
Quanto às ações que deverão ser tomadas com os pacotes, existem ações obrigatórias
que todos os switches OpenFlow devem implementar e outras opcionais. Ao se conectar
ao controlador, o switch deve informar quais ações opcionais o mesmo implementa. Cada
entrada na tabela de �uxos é associada a uma ou mais ações. Se para uma determinada
entrada na tabela não houver uma ação especi�cada, os pacotes desse �uxo serão descartados.
Abaixo seguem os tipos de ações:
• Encaminhamento
� Obrigatório
∗ ALL - Envia o pacote para todas as interfaces, exceto a interface de entrada;
∗ CONTROLLER - Encapsula e envia o pacote para o controlador;
∗ LOCAL - Envia o pacote para a pilha de rede local;
∗ TABLE - Realiza ações na tabela de �uxos;
∗ IN_PORT - Envia o pacote para a porta de entrada;
� Opcional
∗ NORMAL - Processa o pacote utilizando um encaminhamento tradicional;
∗ FLOOD - Inunda o pacote, sem incluir a interface de entrada, levando em
consideração o Spanning Tree.
4.3 TABELA DE FLUXOS 26
• En�leirar (opcional) - Encaminha o pacote através de uma �la relacionada a uma
porta;
• Descartar (obrigatória)
• Modi�car campo (opcional)
� Setar Vlan ID
� Setar Vlan Priority
� Separar o cabeçalho da Vlan
� Modi�car endereço MAC (Media Access Control) de origem
� Modi�car endereço MAC de destino
� Modi�car endereço IP de origem
� Modi�car endereço IP de destino
� Modi�car ToS
� Modi�car a porta de transporte de origem
� Modi�car a porta de transporte de destino
A Figura 4.5, apresenta o �uxograma referente a entrada de um pacote em um switch
OpenFlow.
Figura 4.5: Fluxograma do processamento dos pacotes.
Fonte: Foundation (2009)
Vale salientar que, assim como nos roteadores rotas para sub-redes mais especí�cas têm
prioridade, entradas na tabela de �uxos que especi�quem exatamente o �uxo entrante, ou
seja, entradas na tabela que não apresentem campos coringa, terão sempre a mais alta
prioridade.
4.3 O CANAL SEGURO 27
4.3 O canal seguro
Outra parte essencial da caracterização de um switch OpenFlow é o estabelecimento
de um canal seguro com o controlador. Através desse canal, o controlador irá con�gurar e
gerenciar o switch OpenFlow. De acordo com Comer (2013), embora uma conexão TCP seja
permitida entre o switch e o controlador, o uso de SSL/TLS é recomendado com o objetivo
de garantir con�dencialidade em toda comunicação. É importante lembrar que o OpenFlow
não requer uma conexão física direta entre o switch e o controlador, podendo utilizar redes
já em produção para efetuar a comunicação. Por isso, a importância de um canal seguro.
O protocolo OpenFlow suporta três tipos diferentes de mensagens:
• Controlador-Switch - Geradas pelo controlador para gerenciar e inspecionar o estado
de um switch;
• Assíncronas - Geradas pelo switch para atualizar o controlador sobre eventos da rede
e mudanças no estado do switch;
• Simétricas - Podem ser geradas tanto pelo controlador quanto pelo switch. São enviadas
sem solicitação;
Abaixo, os sub-tipos de cada uma:
• Controlador-Switch
� Características (Features) - O controlador requisita as características do switch.
O switch deve responder com as características suportadas;
� Con�guração (Con�guration) - Usado para con�gurar ou solicitar con�gurações
do switch;
� Modi�cação de estado (Modify-State) - Usado para adicionar, deletar e modi�car
a tabela de �uxos e para setar propriedades nas portas do switch;
� Leitura de estado (Read-State) - Coleta estatísticas;
� Envio de pacote (Send-Packet) - Utilizado para enviar pacotes por uma determi-
nada porta do switch;
� Barreira (Barrier) - Usado para garantir que as dependências foram atendidas
ou para receber noti�cações de operações �nalizadas;
• Assíncrona
� Entrada de pacotes (Packet-In) - Utilizado quando �uxos não classi�cados entram
no switch.
� Remoção de �uxo (Flow-Removed) - Mensagem enviada para o controlador, quando
um �uxo é removido da tabela. Seja por Idle Timeout, Hard Timeout ou por uma
mensagem de modi�cação da tabela de �uxos que delete a entrada em questão;
4.3 O CANAL SEGURO 28
� Estado da porta (Port-Status) - Mensagem enviada para o controlador sempre
que há mudanças nas con�gurações das portas;
� Erro (Error) - Noti�cações de erros;
• Simétrica
� Hello - Mensagens trocadas entre o controlador e o switch quando uma conexão
é estabelecida;
� Echo - Mensagens usadas para identi�cação de latência, largura de banda e exis-
tência de conectividade;
� Vendor - Provêem uma forma padrão para os switches OpenFlow oferecerem
funcionalidades adicionais;
No estabelecimento de uma comunicação OpenFlow, cada um dos lados (controlador e
switch) devem enviar imediatamente uma mensagem Hello (OFPT_HELLO), contendo a
mais alta versão do protocolo OpenFlow suportada pelo dispositivo. Ao receber a mensagem,
o dispositivo deve escolher a menor versão do OpenFlow entre a que foi enviada e recebida.
Se as versões forem compatíveis, a comunicação tem continuidade. Caso não sejam, uma
mensagem de erro é gerada (OFPT_ERROR) e a conexão é encerrada.
É interessante informar também que, caso haja alguma perda de conexão entre o switch
e o controlador, o switch tentará se conectar ao controlador back-up, caso exista. Caso essa
conexão também falhe, o switch entrará em modo de emergência, modo esse que utilizará
apenas as entradas na tabela de �uxos marcadas com um bit de emergência e todas as outras
entradas serão deletadas.
Para modi�car as tabelas de �uxos dos switches, o controlador poderá gerar cinco tipos
de mensagens diferentes. A Figura 4.6 ilustra esses tipos:
Figura 4.6: Tipos de mensagens para modi�cação da tabela de �uxos.
Fonte: Foundation (2009)
Como pode ser observado, as mensagens ADD adicionarão entradas na tabela de �uxos,
as mensagens do tipo MODIFY modi�carão entradas já existentes e as mensagens do tipo
DELETE apagarão entradas na tabela de �uxo. As mensagens *_STRICT (OFPFC_MODIFY_STRICT
e OFPFC_DELETE_STRICT) buscarão entradas na tabela de �uxos idênticas às especi-
�cadas.
Além das mensagens OFPFC_DELETE e OFPFC_DELETE_STRICT as entradas na
tabela de �uxos podem ser removidos por idle_timeout ou hard_timeout. Caso não entrem
4.4 OUTRAS VERSÕES 29
pacotes correspondentes a uma determinada entrada na tabela em idle_timeout segundos
ou caso transcorra hard_timeout segundos após a inserção da entrada na tabela, a entrada
será apagada.
4.4 Outras versões
Nas seções acima, o OpenFlow 1.0.0 foi apresentado em maiores detalhes, considerando
que o mesmo é a versão mais utilizada e difundida. Entretanto, muitas mudanças foram
realizadas desde o lançamento da versão 1.0.0 até a versão mais atual, a 1.4. Abaixo, seguem
algumas características das versões subsequentes:
4.4.1 OpenFlow 1.1
Na especi�cação do OpenFlow 1.1, os switches OpenFlow contêm diversas tabelas de
�uxos e uma tabela de grupo, ao invés de uma única tabela de �uxos como na versão 1.0.0.
A Imagem 4.7 ilustra os componentes do switch OpenFlow 1.1. Nela podem ser vistas as
diversas tabelas de �uxos, assim como, a tabela de grupo. Ja a Imagem 4.8 ilustra como é
o processamento de pacotes ao entrarem em um switch OpenFlow 1.1.
Figura 4.7: Componentes de um switch OpenFlow 1.1
Fonte: Foundation (2011a)
4.4 OUTRAS VERSÕES 30
Figura 4.8: Fluxograma detalhando o �uxo de pacotes através do switch OpenFlow 1.1
Fonte: Foundation (2011a)
Logo, um �uxo de pacotes ao entrar no switch OpenFlow, poderá passar por várias
tabelas de �uxos, para que diversas ações diferentes sejam realizadas.
A tabela de grupo é um tipo especial de tabela projetada para executar ações que sejam
comuns para diversos �uxos.
Além disso, na versão 1.1.0 , três novos campos de cabeçalho foram incluídos: Metadata
(pode ser usada para passar informações entre as tabelas no switch), MPLS label e MPLS
tra�c class.
Maiores detalhes podem ser encontrados na especi�cação OpenFlow 1.1.0 em Foundation
(2011a).
4.4.2 OpenFlow 1.2
O OpenFlow 1.2 foi lançado em dezembro de 2011 e uma das principais implementações
foi o suporte ao protocolo IPv6, incluindo novos campos de cabeçalho nas tabelas de �uxos.
Além disso, o mesmo passou a suportar a possibilidade dos switches se conectarem a mais
de um controlador ao mesmo tempo. Ao se conectar a vários controladores, aumenta-se a
segurança já que o switch pode continuar a operar normalmente mesmo se um controlador
ou a conexão �car indisponível Lara et al. (2014).
Maiores detalhes em Foundation (2011b).
4.4 OUTRAS VERSÕES 31
4.4.3 OpenFlow 1.3
Sendo lançada em Junho de 2012, a versão 1.3.0 do OpenFlow passou a suportar o
controle das taxas de pacotes através de medidores de �uxos, introduzindo a tabela de
medições (Meter Table). A tabela de medições por �uxo permite ao OpenFlow implementar
simples operações de QoS, como limitação de taxas de transmissão e pode ser combinada
com as �las por porta para criar políticas de QoS mais complexas. Além disso, a versão
1.3 permite ao switch criar conexões auxiliares para o controlador, ajudando a melhorar o
desempenho de processamento do switch, explorando o paralelismo presente na maioria dos
switches Foundation (2012a).
4.4.4 OpenFlow 1.4
Na versão 1.4 do OpenFlow portas ópticas passaram a ser suportadas. Além disso, os
conceitos de Eviction e Vacancy events foram introduzidos para evitar que as tabelas de
�uxos �quem cheias, já que as mesmas tem capacidades �nitas. Nas especi�cações anteriores
quando uma tabela de �uxos enchia, novos �uxos não eram inseridos nas tabelas e uma
mensagem de erro era enviada para o controlador. Entretanto, atingir tal situação era pro-
blemático e poderia causar interrupções no serviço. O Eviction adiciona um mecanismo que
permite ao switch apagar automaticamente as entradas nas tabelas de �uxos que tenham
menor importância. Já o Vacancy events permite ao controlador con�gurar um limiar, que
ao ser atingido, faz o switch enviar mensagens de alerta para o controlador. Isso permite
que o controlador possa reagir com antecedência, evitando que as tabelas de �uxos �quem
cheias Foundation (2012b).
As subseções acima deram apenas uma visão global sobre as características das ver-
sões do OpenFlow posteriores à 1.0.0. Maiores detalhes e outras características podem ser
encontradas nas especi�cações técnicas, citadas na bibliogra�a.
4.5 POX 32
4.5 POX
Como visto anteriormente, o controlador é parte fundamental nas redes de�nidas por soft-
ware, já que serão os mesmos que irão de�nir a lógica de encaminhamento através das regras
que irão con�gurar nos switches OpenFlow. Atualmente, existem alguns disponíveis para o
uso, como o NOX (Gude et al. , 2008), POX (http://www.noxrepo.org/pox/about pox/ ),
Maestro (Cai et al. , 2010), Trema (http://trema.github.io/trema/ ), Beacon (Erickson ,
2013), entre outros como pode ser visto na Figura 4.9.
Figura 4.9: Alguns controladores OpenFlow existentes
Fonte: Nunes et al. (2014)
O controlador utilizado nesse trabalho foi o POX. O mesmo é derivado do NOX clássico,
um dos primeiros controladores OpenFlow. O POX apresenta como vantagens o fato de ser
implementado em Python, sendo ideal para o ambiente acadêmico. Além disso, o mesmo
apresenta diversos componentes reusáveis e bibliotecas interessantes como as seguintes:
• open�ow.discovery: Utiliza mensagens LLDP (Link Layer Discovery Protocol) para
descobrir a conectividade entre os switches com o objetivo de mapear a topologia da
rede. O mesmo cria eventos (os quais podem ser �escutados�) quando um link �ca up
ou down. Esse componente foi essencial para a aplicação desenvolvida;
• open�ow.spanning_tree: Esse componente utiliza o discovery para contruir uma vi-
são da topologia da rede e constrói uma spanning tree para desabilitar a inundação
(�ooding) nas portas dos switches que não estão na árvore;
• pox.lib.revent: Biblioteca do POX que implementa eventos. Todos eventos do POX são
instâncias de sub-classes da classe Event ;
• pox.lib.recoco: Biblioteca do POX que implementa threads e timers ;
• pox.lib.addresses: Biblioteca utilizada para lidar com endereços IP e Ethernet (MAC);
Capítulo 5
Mininet
O ambiente utilizado para o desenvolvimento da aplicação e realização dos testes foi o
Mininet. Este se trata de um emulador de redes, desenvolvido por pesquisadores da Univer-
sidade de Stanford nos Estados Unidos, com o objetivo de apoiar pesquisas colaborativas
permitindo protótipos autônomos de redes de�nidas por software, para que qualquer pessoa
possa fazer o download, executar, avaliar, explorar e ajustar Lantz et al. (2010).
O Mininet é um emulador do tipo CBE (Container-Based Emulation) que emprega a vir-
tualização a nível de processo, uma forma mais leve de virtualização onde muitos recursos do
sistema são compartilhados. Compartilhando recursos como tabela de paginação, estruturas
de dados do kernel e sistema de arquivos, esse tipo de emulação alcança maior escalabilidade
que outras que realizam uma emulação completa, ou seja, usando uma máquina virtual para
cada dispositivo da rede Heller (2013).
Na Imagem 5.1 é apresentada uma topologia simples que servirá de base para as Imagens
5.2 e 5.3. Nessas duas últimas as diferenças citadas acima, entre CBE e a virtualização
completa, podem ser visualizadas.
Figura 5.1: Topologia simples com dois hosts e um switch.
Fonte: Lantz e O'Connor
33
5.0 34
Figura 5.2: Virtualização completa dos dispositivos.
Fonte: Lantz e O'Connor
Figura 5.3: Virtualização "leve"dos dispositivos.
Fonte: Lantz e O'Connor
O Mininet é capaz de emular links, hosts, switches e controladores, utilizando processos
que rodem em espaços de nomes da rede (network namespaces) e pares Ethernet virtuais.
• Links: Um par Ethernet virtual atua como um cabo conectando duas interfaces virtuais.
Pacotes enviados através de uma interface são entregues na outra e cada interface se
comporta como uma interface Ethernet completa e funcional para todo o sistema e
aplicação.
• Host: É simplesmente um processo do shell movido para o seu próprio espaço de nome
da rede, ou seja, cada host apresenta uma instância da interface de rede independente.
Cada dispositivo apresenta uma ou mais interfaces virtuais e um pipe para um processo
pai do Mininet (mn), que envia comandos e monitora a saída.
• Switches: Switches OpenFlow são remotamente con�gurados e gerenciados pelo con-
5.0 35
trolador, podendo ser con�gurados para agirem como switches convencionais.
• Controladores: Controladores OpenFlow podem estar em qualquer lugar da rede, ou
seja, tanto na rede física quanto na virtual Lantz et al. (2010).
Para controlar e gerenciar todos os dispositivos emulados, o Mininet fornece uma CLI
(Command Line Interface) conhecedora de toda a rede, ou seja, através de um único console,
pode-se controlar todos os dispositivos emulados. Outra grande vantagem desse emulador
é a facilidade de criação de topologias customizadas através de uma API (Application Pro-
gramming Interface) para programação em Python.
O projeto Mininet nasceu com o objetivo de facilitar os experimentos no campo de
redes de computadores, principalmente para auxiliar nas pesquisas das redes de�nidas por
software e do OpenFlow. Pode ser veri�cado em Heller (2013) uma análise completa do
Mininet, incluindo uma comparação entre os tipos de plataformas para pesquisas em redes
de computadores mais comuns, os simuladores, testbeds e emuladores.
Em Handigol et al. (2012), pode ser veri�cada a robustez do Mininet ao reproduzir
diversos experimentos de redes de computadores escolhidos por estudantes.
O emulador Mininet encontra-se em constante evolução, sendo mantido por uma ativa
comunidade online. O mesmo encontra-se na versão 2.1.0 lançada em Setembro de 2013.
Capítulo 6
A aplicação desenvolvida
Com a tecnologia de redes de computadores atual, torna-se inviável o teste de novos
protocolos em redes que estejam em produção, já que as mesmas foram implementadas com
hardwares especí�cos, que não permitem uma reprogramação.
Conforme visto nos capítulos anteriores, com as redes de�nidas por software, essa li-
mitação já não mais existirá. Equipamentos especí�cos se tornam genéricos e a �gura do
controlador aparece para que possa existir uma rede programável e para que mudanças na
forma de encaminhar os pacotes possam ser realizadas rapidamente.
A aplicação desenvolvida busca mostrar essa facilidade presente nas redes de�nidas por
software.
A mesma foi desenvolvida para alterar o roteamento de um �uxo pré-determinado,
quando o uso da largura de banda do caminho inicial estiver alto. Para tal, foram utili-
zados conceitos do algoritmo de Dijkstra para o cálculo dos caminhos e módulos presentes
no POX, como será visto adiante.
6.1 Executando a aplicação
Ao se inicilizar a aplicação, a primeira ação que é realizada é a descoberta da rede. O
módulo discovery presente no POX faz a descoberta da conectividade entre swicthes Open-
Flow enviando pacotes LLDP. A Imagem 6.1, gerada através de uma captura no Wireshark,
mostra os pacotes LLDP:
Figura 6.1: Pacotes LLDP.
36
6.1 EXECUTANDO A APLICAÇÃO 37
Conforme a descoberta vai sendo feita, um peso é atribuido aos enlaces. Esse peso pode ser
interpretado como o delay do link por exemplo ou qualquer outro parâmetro que signi�que
que quanto maior o valor, pior é o enlace. Para a emulação realizada, se utilizou um gerador
de números aleatórios para a de�nição dos pesos de cada enlace. Após a topologia ser salva,
com a descoberta de todos os switches e a atribuição dos pesos, o algoritmo de Dijkstra é,
então, executado em um codigo complementar.
Esse código complementar (Anexo 10.1), utiliza conceitos do algoritmo de Dijkstra para
realizar o cálculo da melhor e da segunda melhor rotas entre os switches OpenFlow. O código
recebe como parâmetros o nó origem e a topologia e retorna duas listas, uma contendo o
menor custo e a outra contendo o segundo menor custo para se chegar aos outros nós.
A Figura 6.2 apresenta um �uxograma representando essa primeira etapa:
Figura 6.2: Fluxograma representando primeira etapa da execução da aplicação.
Como pode ser visto no �uxograma acima, toda vez que ocorrer um evento de link, ou
seja, quando um link for descoberto ou quando um link �car down, a topologia será alterada
e o código 10.1 será executado.
Ao receber um pacote, o switch enviará uma mensagem de Packet-In para o controlador,
se o switch não possuir entradas em sua tabela de �uxos. A aplicação no controlador tratará
de maneiras diferentes pacotes ARP (Address Resolution Protocol) e os demais. Se o pacote
for um ARP (seja Request ou Reply) o controlador irá gerar um pacote de Packet-Out, ou
seja, o controlador informa ao switch apenas qual deve ser a ação a ser tomada para um
pacote, não havendo modi�cação da tabela de �uxos do switch. A Figura 6.3, mostra os
Packet-In gerados pelos switches, com a resposta Packet-Out do controlador:
Figura 6.3: Pacotes ARP e respota do controlador.
6.1 EXECUTANDO A APLICAÇÃO 38
Caso o pacote não seja ARP, o controlador gera uma mensagem de Flow-Mod que irá
inserir uma entrada na tabela de �uxos do switch, como pode ser visto na Figura 6.4.
Figura 6.4: Resposta do controlador para outros pacotes.
Segue na Imagem 6.5, �uxograma dos passos citados acima.
Figura 6.5: Fluxograma representando o evento de Packet-In.
Para cada par de switches origem e destino, a aplicação monitora a taxa de transmissão,
fazendo requisições periódicas de estatísticas do uso da interface. A quantidade de bytes
transmitidos pela porta conectada ao próximo switch (próximo switch de acordo com o
melhor caminho calculado) é salva em uma variável e será comparada com a quantidade da
coleta anterior.
Como na topologia de�nida para o teste (Anexo 9.1) os links foram de�nidos com uma
largura de banda de 100 Mbps, é feito um cálculo com a diferença de bytes transmitidos
em duas coletas e veri�ca-se se a quantidade de bits transmitidos por segundo é menor que
um determinado limiar. Esse limiar foi determinado nos testes como 70 Mbps. Caso seja,
todos os �uxos destinados ao mesmo IP de destino passam pelo melhor caminho. Caso a
quantidade de bits por segundo seja maior que 70 Mpbs, os �uxos que apresentem porta
UDP igual a 2000 são chaveados para a segunda melhor rota.
6.1 EXECUTANDO A APLICAÇÃO 39
Figura 6.6: Fluxograma do teste de links e chaveamento entre caminhos.
Como pode ser visto no �uxograma da Figura 6.6, com o objetivo de evitar que �quem
ocorrendo mudanças de rotas a todo momento, foi implementada uma histerese. Assim,
existe um contador que salva o número de ocorrências do evento. Para mudar para o segundo
caminho, o mesmo deve ser maior ou igual a 2 (10 segundos). Para que o �uxo volte para
o melhor caminho, o uso da banda do melhor caminho deve �car abaixo de 70Mbps por
no mínimo o tempo que �cou acima desse limiar. Vale ressaltar que o valor máximo desse
contador é 5 (25 segundos).
O incremento desse contador, assim como outros detalhes menores, não foi indicado no
�uxograma 1.
A aplicação mostra como o controlador pode agir proativamente com o objetivo de evitar
sobrecarga do link e descartes ou até mesmo para a implementação de políticas de QoS de
forma facilitada. Vale ressaltar, que a escolha da porta UDP 2000 foi feita de forma aleatória
e, com facilidade, o código pode ser generalizado para quaisquer portas ou até mesmo para
que altere a rota levando em consideração quaisquer outros campos de cabeçalho de�nidos
em 4.2.
O código completo desenvolvido pode ser analisado no Anexo 11.1.
1Em um primeiro momento, optou-se pela captura da quantidade de pacotes descartados pela interface.Quando o mesmo chegasse a um limiar estabelecido, ocorreria o chaveamento do �uxo para o segundo melhorcaminho. Entretanto mesmo após estressar o link, o contador dos pacotes descartados não foi incrementado.Acreditando ser uma limitação do Mininet, optou-se então pela análise da utilização da largura de banda
Capítulo 7
Simulação e resultados
Para a realização dos testes, foi utilizada uma topologia redundante 1.
Como a proposta dessa monogra�a é apresentar as redes de�nidas por software, mos-
trando a facilidade com que aplicações podem ser desenvolvidas, uma topologia simples foi
escolhida para a realização dos testes.
Nela, foram con�gurados três hosts e cinco switches. Todos os enlaces foram de�nidos
com as mesmas características, com o objetivo de facilitar os testes e a análise dos resultados.
As principais características são:
• bw - Largura de banda de 100Mbps;
• loss - Perda do link de 1%;
• delay - Atraso de 5ms;
• max_queue_size - Tamanho máximo da �la de 10000 pacotes;
A Figura 7.1, ilustra a topologia utilizada.
Primeiramente, o Mininet é inicializado com a topologia personalizada criada e com al-
guns parâmetros extras, para que os endereços MAC �quem de forma mais legível e de�nindo
que o controlador será externo, como pode ser visto na Figura 7.2.
Após a inicialização do emulador Mininet, a aplicação é inicializada. Como pode ser
visto na Figura 7.3 a aplicação é iniciada com os módulos já citados do POX, discovery e
spanning_tree (4.5), já que por padrão o spanning_tree não é ativado.
Para gerar o tráfego para os testes, foi utilizado o Iperf (iperf.fr ). Com o Iperf, é possível
con�gurar um host para atuar como servidor, �escutando� em uma determinada porta e
hosts como clientes, que irão enviar tráfegos para o servidor.
1Descrição da topologia para o Mininet de�nida no Anexo 9.1
40
7.1 METODOLOGIA 41
Figura 7.1: Topologia utilizada nos testes.
Figura 7.2: Inicialização do Mininet.
Figura 7.3: Inicialização da aplicação.
7.1 Metodologia
Na topologia con�gurada, o host 3 foi de�nido como o servidor, e os hosts 1 e 2 como
clientes. Logo, os hosts 1 e 2 gerarão tráfegos para o host 3. De�niu-se que os pacotes enviados
pelo host 1 seriam pacotes UDP com a porta de destino 1000. Já o host 2 envia pacotes
UDP, usando como porta de destino a 2000. Além disso, ambas comunicações tentarão
utilizar 100% da largura de banda e ambos os �uxos são gerados por 180 segundos, ao
mesmo tempo, como pode ser visto nas Figuras 7.4 e 7.5.
Primeiramente, foram realizados os testes com os dois hosts clientes enviando �uxos por
caminhos diferentes, ou seja, o primeiro host enviando pelo melhor caminho e o segundo host
enviando pelo segundo melhor caminho. O objetivo desse procedimento é conhecer os erros
intrínsecos de cada caminho, para que se tenha uma base de comparação para os próximos
procedimentos.
Cada um dos procedimentos foi repetido seis vezes, sendo cada um deles executados após
a inicialização do Mininet e do controlador.
7.1 METODOLOGIA 42
Figura 7.4: Comandos do Iperf nos clientes.
Figura 7.5: Comandos do Iperf no servidor.
A Figura 7.6, apresenta o grá�co do percentual de pacotes perdidos.
O �uxo 1, é o �uxo enviado pelo host 1 e o �uxo 2, é o enviado pelo host 2.
A Figura 7.7 apresenta a resposta do servidor, após o primeiro teste.
7.1 METODOLOGIA 43
Figura 7.6: Percentual da perda de pacotes com os �uxos sendo enviados sempre por caminhosdiferentes.
Figura 7.7: Teste com dois hosts enviando por caminhos diferentes.
Em seguida, foram realizados os testes com ambos os �uxos sendo enviados pelo melhor
caminho. O objetivo é veri�car qual é a porcentagem dos pacotes perdidos, sem utilizar o
chaveamento para o segundo melhor caminho.
O grá�co com o percentual de perda dos pacotes, nos seis testes realizados, é apresentado
na Figura 7.8.
Na Figura 7.9 segue resposta do servidor após o primeiro teste.
7.1 METODOLOGIA 44
Figura 7.8: Percentual da perda de pacotes com ambos os �uxos sendo enviados sempre pelo melhorcaminho.
Figura 7.9: Teste com dois hosts enviando pelo mesmo caminho.
Por �m, realiza-se o teste com o chaveamento dinâmico ativado. A con�guração do ca-
minho alternativo é efetuada caso a utilização da largura de banda �que acima de 70Mbps.
O resultado pode ser visto na Figura 7.10.
A Figura 7.11 apresenta a resposta do servidor após o primeiro teste.
Na Figura 7.12, segue a tabela de �uxos do switch 1, mostrando a modi�cação da interface
de saída para os �uxos que tenham porta UDP igual a 2000.
7.1 METODOLOGIA 45
Figura 7.10: Percentual da perda dos pacotes, realizando a mudança de rota dinamicamente.
Figura 7.11: Resultado do primeiro teste.
Os grá�cos dos percentuais médios de cada procedimento são apresentados na Figura
7.13. Já o grá�co com as taxas médias de transmissão dos �uxos é apresentado na Figura
7.14.
Figura 7.12: Tabela de �uxos do switch 1.
7.1 METODOLOGIA 46
Figura 7.13: Percentual médio dos erros
Figura 7.14: Taxa de transmissão média
Como pode ser veri�cado, o uso da aplicação reduziu consideravelmente as perdas de
pacotes de todos os �uxos, chegando a valores próximos ao experimento dos �uxos sempre
por caminhos diferentes. Para os testes em questão, que foram realizados por um período de
180 segundos, a redução de 1% na perda dos pacotes, equivale a um ganho na recepção de
aproximadamente 8000 pacotes!
Considerando que a redução da perda foi de aproximadamente 5%, �ca bastante clara a
7.1 METODOLOGIA 47
melhoria na entrega dos pacotes.
Capítulo 8
Conclusões
Esse trabalho teve como objetivo introduzir um paradigma diferente da atual implemen-
tação de redes de computadores. Modelo esse que pode vir a ser o predominante em poucos
anos.
Buscando ajudar na compreenssão das redes de�nidas por software, no Capítulo 2, con-
ceitos básicos de redes de computadores foram explanados. Conceitos como modelo em ca-
madas, encaminhamento, roteamento e classi�cação de pacotes, serviram como uma base
para os conceitos seguintes.
O Capítulo 3 de�ne as redes de�nidas por software, modelo que propõe a separação dos
planos de controle e dados, planos esses encontrados nos dispositivos de redes como switches
e roteadores. Com sua separação, é possivel ter um controle total da rede. Já não são mais
necessários hardwares especí�cos, mas hardwares genéricos podem ser utilizados e, através
do controlador, podem ser programados.
O Capítulo 4 apresenta o OpenFlow, implementação mais difundida das redes de�nidas
por software. Um enfoque maior é dado a versão 1.0.0, a versão mais utilizada do OpenFlow.
Entretanto, as diferenças entre as versões mais novas como as versões 1.1, 1.2, 1.3 e 1.4 são
citadas. Nesse capítulo, é apresentado também o POX, controlador implementado em Python
e que foi utilizado nesse trabalho.
No Capítulo 5, o Mininet é apresentado. O mesmo é um emulador de redes desenvolvido
na universidade de Stanford, cuja principal vantagem é o fato de empregar uma forma mais
leve de virtualização, onde muitos recursos do sistema são compartilhados.
Nos Capítulos seguintes, a aplicação é �nalmente descrita e seus resultados mostrados.
Como foi visto, uma topologia simples com cinco switches e três hosts foi utilizada. Fluxos
são gerados por dois hosts clientes para o servidor e de acordo com a utilização da largura
de banda, o caminho de um desses �uxos pode ser alterado.
Como visto, foram realizados três procedimentos. No primeiro, foram realizadas uma série
de testes com o objetivo de descobrir a perda intrínseca dos caminhos. Ao fazer isso, encontra-
se uma base, com a qual poderão ser comparados os resultados dos próximos procedimentos.
No segundo procedimento, testes são realizados com os dois �uxos sendo enviados pelo
48
8.0 49
mesmo caminho. O objetivo é veri�car a quantidade de pacotes que estão sendo perdidos
devido à utilização do mesmo link.
No terceiro procedimento, os testes realizados utilizam a aplicação para realizar o cha-
veamento de um �uxo especí�co (no caso, o �uxo cuja porta UDP de destino seja 2000).
O mesmo passa a utilizar o segundo melhor caminho calculado pelo algoritmo de Dijkstra,
caso a utilização do link principal seja maior ou igual a 70Mbps.
No �nal do capítulo, um grá�co comparativo dos três procedimentos é apresentado. Nele,
percebe-se que a utilização do algoritmo que realiza a troca de rotas dinamicamente reduziu
em torne de 5% a perda de pacotes.
Logo, a prova de conceito foi realizada com sucesso. Os resultados �caram dentro do es-
perado e da proposta inicial. Ainda, o código da aplicação futuramente pode ser modi�cado,
buscando deixá-lo mais genérico ou adequando-o a uma outra situação especí�ca.
Capítulo 9
Apêndice A
9.1 Código para criação da topologia
#Topologia − 5 sw i t ch e s − 3 ho s t s
from mininet . topo import Topo
class MyTopo( Topo ) :
def __init__( s e l f ) :
Topo . __init__( s e l f )
h1 = s e l f . addHost ( ' h1 ' )
h2 = s e l f . addHost ( ' h2 ' )
h3 = s e l f . addHost ( ' h3 ' )
s1 = s e l f . addSwitch ( ' s1 ' )
s2 = s e l f . addSwitch ( ' s2 ' )
s3 = s e l f . addSwitch ( ' s3 ' )
s4 = s e l f . addSwitch ( ' s4 ' )
s5 = s e l f . addSwitch ( ' s5 ' )
#Adicionando l i n k s
s e l f . addLink ( h1 , s1 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( h2 , s1 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( h3 , s5 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
50
9.1 CÓDIGO PARA CRIAÇÃO DA TOPOLOGIA 51
s e l f . addLink ( s1 , s2 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( s1 , s3 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( s1 , s4 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( s2 , s5 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( s3 , s5 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
s e l f . addLink ( s4 , s5 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,
use_htb=True )
topos = { 'mytopo ' : ( lambda : MyTopo( ) ) }
Código 9.1: Código topologia.py em Python para a criação da topologia, de�nindo a quantidade
de hosts, swicthes e características dos enlaces
Capítulo 10
Apêndice B
10.1 Código para calcular as rotas
# Executa a l gor i tmo de Di jaks t ra , ca l cu lando o melhor e o segundo melhor
caminho ;
def recebe_dados ( no_origem , t opo l og i a ) :
d i s t a n c i a s = {}
distanc ias_segundo = {}
v i z i nho s = {}
vizinhos_segundo = {}
num_nos , nos = calcula_num_nos ( t opo l og i a )
nos_segundo = nos [ : ]
for no in nos :
v i z i nho s [ no ] = [ ]
for i in t opo l og i a :
i f ( no == i [ 0 ] ) :
v i z i nho s [ no ] . append ( [ i [ 2 ] , i [ 1 ] ] )
i f ( no == i [ 2 ] ) :
v i z i nho s [ no ] . append ( [ i [ 0 ] , i [ 1 ] ] )
i f ( no != no_origem ) :
d i s t a n c i a s [ no ] =[−1,−1, 0 ]
for no_segundo in nos_segundo :
viz inhos_segundo [ no_segundo ] = [ ]
for i in t opo l og i a :
i f ( no_segundo == i [ 0 ] ) :
viz inhos_segundo [ no_segundo ] . append ( [ i [ 2 ] , i [ 1 ] ] )
52
10.1 CÓDIGO PARA CALCULAR AS ROTAS 53
i f ( no_segundo == i [ 2 ] ) :
viz inhos_segundo [ no_segundo ] . append ( [ i [ 0 ] , i [ 1 ] ] )
i f ( no_segundo != no_origem ) :
d i s tanc ias_segundo [ no_segundo ] =[−1,−1, 0 ]
for j in v i z i nho s [ no_origem ] :
d i s t a n c i a s [ j [ 0 ] ] = j
d i s t a n c i a s [ j [ 0 ] ] . append (0 )
for l in vizinhos_segundo [ no_origem ] :
d i s tanc ias_segundo [ l [ 0 ] ] = l
d i s tanc ias_segundo [ l [ 0 ] ] . append (0)
v i s i t a d o = 0
while v i s i t a d o == 0 :
peso_minimo = −1no_custo_minimo = None
v i s i t a d o = 1
for j in d i s t a n c i a s :
i f ( d i s t a n c i a s [ j ] [ 2 ] == 0) :
i f ( d i s t a n c i a s [ j ] [ 1 ] != −1) :i f ( ( peso_minimo == −1) or ( peso_minimo > d i s t a n c i a s [ j ] [ 1 ] ) ) :
peso_minimo = d i s t a n c i a s [ j ] [ 1 ]
no_custo_minimo = j
v i s i t a d o = 0
i f v i s i t a d o == 0 :
for v i z inho in v i z i nho s [ no_custo_minimo ] :
i f v i z inho [ 0 ] != no_origem :
i f ( d i s t a n c i a s [ no_custo_minimo ] [ 1 ] + v i z inho [ 1 ] <= d i s t a n c i a s [
v i z inho [ 0 ] ] [ 1 ] ) or ( d i s t a n c i a s [ v i z inho [ 0 ] ] [ 1 ] == −1) :d i s t a n c i a s [ v i z inho [ 0 ] ] [ 0 ] = d i s t a n c i a s [ no_custo_minimo ] [ 0 ]
d i s t a n c i a s [ v i z inho [ 0 ] ] [ 1 ] = d i s t a n c i a s [ no_custo_minimo ] [ 1 ] +
v i z inho [ 1 ]
d i s t a n c i a s [ no_custo_minimo ] [ 2 ] = 1
vis i tado_segundo = 0
while vis i tado_segundo == 0 :
10.1 CÓDIGO PARA CALCULAR AS ROTAS 54
peso_minimo_segundo = −1no_custo_minimo_segundo = None
vis i tado_segundo = 1
for j in distanc ias_segundo :
i f ( d i s tanc ias_segundo [ j ] [ 2 ] == 0) :
i f ( d i s tanc ias_segundo [ j ] [ 1 ] != −1) :i f ( ( peso_minimo_segundo == −1) or ( peso_minimo_segundo >
distanc ias_segundo [ j ] [ 1 ] ) ) :
peso_minimo_segundo = distanc ias_segundo [ j ] [ 1 ]
no_custo_minimo_segundo = j
vis i tado_segundo = 0
i f vis i tado_segundo == 0 :
for v i z inho in vizinhos_segundo [ no_custo_minimo_segundo ] :
i f v i z inho [ 0 ] != no_origem :
soma_distancias = distanc ias_segundo [ no_custo_minimo_segundo ] [ 1 ]
+ v i z inho [ 1 ]
i f ( ( soma_distancias < distanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] ) or (
d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] == −1) ) :
i f ( ( soma_distancias > d i s t a n c i a s [ v i z inho [ 0 ] ] [ 1 ] or
distanc ias_segundo [ no_custo_minimo_segundo ] [ 0 ] !=
d i s t a n c i a s [ no_custo_minimo_segundo ] [ 0 ] ) ) :
d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] = distanc ias_segundo [
no_custo_minimo_segundo ] [ 0 ]
d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] = soma_distancias
i f ( ( d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] == d i s t a n c i a s [ v i z inho
[ 0 ] ] [ 0 ] ) and ( d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] == d i s t a n c i a s
[ v i z inho [ 0 ] ] [ 1 ] ) ) :
i f ( d i s t a n c i a s [ no_custo_minimo_segundo ] [ 0 ] !=
distanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] ) :
d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] = no_custo_minimo_segundo
distanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] = d i s t a n c i a s [
no_custo_minimo_segundo ] [ 1 ] + v i z inho [ 1 ]
else :
d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] = no_custo_minimo_segundo
distanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] = distanc ias_segundo [
no_custo_minimo_segundo ] [ 1 ] + v i z inho [ 1 ]
d i s tanc ias_segundo [ no_custo_minimo_segundo ] [ 2 ] = 1
10.1 CÓDIGO PARA CALCULAR AS ROTAS 55
#For nece s sa r i o dev ido ao problema quando um no so t inha um unico
v i z i nho e nao era v i s i t a d o para c a l c u l a r o segundo melhor caminhos .
#Try nece s sa r i o po i s como o Djaks tra e chamado antes de toda a t o po l o g i a
e s t a r criada , e l e dava excep t i on . Caso o codigo s e j a chamado apenas
apos a cr iacao de toda a topo l og i a , a excecao nao aparecera mais .
try :
for chaves in vizinhos_segundo . keys ( ) :
i f vizinhos_segundo [ chaves ] [ 0 ] != no_origem :
i f len ( viz inhos_segundo [ chaves ] ) == 1 and distanc ias_segundo [
chaves ] [ 0 ] == −1:d i s tanc ias_segundo [ chaves ] [ 1 ] = distanc ias_segundo [
viz inhos_segundo [ chaves ] [ 0 ] [ 0 ] ] [ 1 ] + vizinhos_segundo [ chaves
] [ 0 ] [ 1 ]
d i s tanc ias_segundo [ chaves ] [ 0 ] = distanc ias_segundo [
viz inhos_segundo [ chaves ] [ 0 ] [ 0 ] ] [ 0 ]
d i s tanc ias_segundo [ chaves ] [ 2 ] = 1
except Exception :
pass
return d i s t an c i a s , d i s tanc ias_segundo
#Calcu la quantos nos ha na t o po l o g i a ;
def calcula_num_nos ( top ) :
Conj_nos = set ( )
for i in top :
Conj_nos . add ( i [ 0 ] )
Conj_nos . add ( i [ 2 ] )
Lista_nos = l i s t (Conj_nos )
Num_nos = len ( Lista_nos )
return Num_nos , Lista_nos
Código 10.1: Código dijkstra.py em Python utilizado para calcular a melhor e a segunda melhor
rotas
Capítulo 11
Apêndice C
11.1 Código da aplicação
from pox . core import core
from pox . l i b . revent import ∗import pox . openf low . l ibopenf low_01 as o f
import pox . openf low . d i s cove ry
import pox . openf low . spanning_tree
from random import randrange
import djakstra_v2
from time import s l e e p
from pox . l i b . addre s s e s import IPAddr
from pox . l i b . r ecoco import Timer
from pox . openf low . of_json import ∗
l og=core . getLogger ( )
class switch_multi ( object ) :
mac_map={}
de lay_l inks={}
def __init__( s e l f ) :
def s ta r tup ( ) :
core . openf low . addLi s t ene r s ( s e l f , p r i o r i t y =0)
core . openf low_discovery . addLi s t ene r s ( s e l f )
#Lis t ene r para eventos e s t a t i s t i c o s
core . openf low . addListenerByName ( "FlowStatsReceived " , s e l f .
handle_flow_stats )
56
11.1 CÓDIGO DA APLICAÇÃO 57
core . openf low . addListenerByName ( "PortStatsRece ived " , s e l f .
handle_ports tats_rece ived )
s e l f . connect i ons = set ( )
core . call_when_ready ( startup , ( ' openf low ' , ' openf low_discovery ' ) )
#Dic ionar io chave − IP ; v a l o r e s − MAC origem e porta do sw i t ch
s e l f .mac_map = {}
s e l f . t opo l og i a = [ ]
s e l f . de lay_l inks = {}
s e l f . por tas = {}
s e l f . dij_1_melhor = [ ]
s e l f . dij_2_melhor = [ ]
s e l f . dij_1_segundo = [ ]
s e l f . dij_2_segundo = [ ]
#Contador que sera u t i l i z a d o para execu tar o Djaks tra . Sem o mesmo , o
a l g o r i t imo de Djaks tra e executado , sem os l i n k s terem s ido
de s cobe r t o s .
s e l f . count = 0
s e l f . l ink_count = 0
s e l f . tx_1 = 0
s e l f . tx_2 = 0
s e l f . d i f e r e n c a = 0
s e l f .LINK_OK = True
s e l f .JA_ENTROU = False
def _handle_LinkEvent ( s e l f , event ) :
chave_1 = str ( event . l i n k . dpid1 )+str ( event . l i n k . dpid2 )
chave_2 = str ( event . l i n k . dpid2 )+str ( event . l i n k . dpid1 )
delay_1 = s e l f . de lay_l inks . get ( chave_1 )
delay_2 = s e l f . de lay_l inks . get ( chave_2 )
i f ( delay_1 == None and delay_2 == None) :
de lay = None
chave = chave_1
e l i f delay_1 != None :
de lay = delay_1
chave = chave_1
else :
de lay = delay_2
chave = chave_2
i f event . added == True :
11.1 CÓDIGO DA APLICAÇÃO 58
#Dic ionar io das conexoes . Retorna o numero da porta de cada conexao
i f not chave_1 in s e l f . por tas . keys ( ) :
s e l f . por tas . update ({ chave_1 : event . l i n k . port1 })
s e l f . por tas . update ({ chave_2 : event . l i n k . port2 })
i f not ( ( [ event . l i n k . dpid1 , delay , event . l i n k . dpid2 ] in s e l f . t opo l og i a
) or ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] in s e l f . t opo l og i a
) ) :
i f delay == None :
s e l f . de lay_l inks . update ({ chave : randrange (5 , 80 , 5 ) })
s e l f . t opo l og i a . append ( [ event . l i n k . dpid1 , s e l f . de lay_l inks . get ( chave
) , event . l i n k . dpid2 ] )
i f event . removed == True :
i f chave_1 in s e l f . por tas . keys ( ) :
s e l f . por tas . remove ({ chave_1 : event . l i n k . port1 })
s e l f . por tas . remove ({ chave_2 : event . l i n k . port2 })
i f ( [ event . l i n k . dpid1 , delay , event . l i n k . dpid2 ] in s e l f . t opo l og i a ) :
s e l f . t opo l og i a . remove ( [ event . l i n k . dpid1 , delay , event . l i n k . dpid2 ] )
i f ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] in s e l f . t opo l og i a ) :
s e l f . t opo l og i a . remove ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] )
print ' t opo l og i a −−−− ' , s e l f . t opo l og i a
s e l f . count = s e l f . count + 1
# PARA TOPOLOGIA COM 6 ENLACES, O CONTADOR CHEGA A 12.
i f s e l f . count >= 12 :
s e l f . dij_1_melhor , s e l f . dij_1_segundo = djakstra_v2 . recebe_dados (1 ,
s e l f . t opo l og i a )
s e l f . dij_2_melhor , s e l f . dij_2_segundo = djakstra_v2 . recebe_dados (2 ,
s e l f . t opo l og i a )
s e l f . dij_3_melhor , s e l f . dij_3_segundo = djakstra_v2 . recebe_dados (3 ,
s e l f . t opo l og i a )
s e l f . dij_4_melhor , s e l f . dij_4_segundo = djakstra_v2 . recebe_dados (4 ,
s e l f . t opo l og i a )
s e l f . dij_5_melhor , s e l f . dij_5_segundo = djakstra_v2 . recebe_dados (5 ,
s e l f . t opo l og i a )
Timer (5 , s e l f . _timer_func , r e cu r r i n g=True )
Timer (5 , s e l f . l ink_tes t , r e cu r r i n g=True )
def _handle_ConnectionUp ( s e l f , event ) :
11.1 CÓDIGO DA APLICAÇÃO 59
#pr in t "Entrou ConnectionUP"
#pr in t "CONECTION −−− " , event . connect ion
s e l f . connect i ons . add ( event . connect ion )
def handle_flow_stats ( s e l f , event ) :
f l ow_stats = f low_stat s_to_l i s t ( event . s t a t s )
def handle_ports tats_rece ived ( s e l f , event ) :
segundo_switch = s e l f . dij_1_melhor [ 5 ] [ 0 ]
chave = str ( "1" ) + str ( segundo_switch )
for i in event . s t a t s :
print "CHAVE −−−−−−−" , chave
i f i . port_no == s e l f . por tas . get ( chave ) :
s e l f . tx_1 = i . tx_bytes
i f ( s e l f . tx_2 != 0) :
s e l f . d i f e r e n c a = ( ( s e l f . tx_1 − s e l f . tx_2 ) ∗8) /5
s e l f . tx_2 = i . tx_bytes
s t a t s = f low_stats_to_l i s t ( event . s t a t s )
def _timer_func ( s e l f ) :
print "−−−−−−−− Entrou timer_func −−−−−−−− "
core . openf low . getConnect ion (1 ) . send ( o f . o fp_stats_request ( body=of .
ofp_flow_stats_request ( ) ) )
core . openf low . getConnect ion (1 ) . send ( o f . o fp_stats_request ( body=of .
ofp_port_stats_request ( ) ) )
def l i nk_te s t ( s e l f ) :
#A cada 5 segundos havera v e r i f i c a c a o do l i n k . O s e l f .LINK_OK comeca
como True . Se a d i f e r enca apos 10 segundos f i c a r acima de 70000000
i f ( s e l f . d i f e r e n c a > 0 and s e l f . d i f e r e n c a < 70000000) :
i f s e l f . l ink_count > 0 :
s e l f . l ink_count = s e l f . l ink_count −1else :
s e l f .LINK_OK = True
else :
i f s e l f . l ink_count < 5 :
s e l f . l ink_count = s e l f . l ink_count + 1
11.1 CÓDIGO DA APLICAÇÃO 60
i f s e l f . l ink_count >= 2 :
s e l f .LINK_OK = False
i f s e l f .JA_ENTROU == False :
msg = of . ofp_flow_mod ( )
msg . match . dl_type = 0x800
msg . match . nw_proto = 17
msg . match . nw_dst = IPAddr ( " 1 0 . 0 . 0 . 3 " )
msg . match . tp_dst = 2000
msg . id le_timeout = 10
msg . hard_timeout = 60
prox_salto2 = s e l f . dij_1_segundo [ 5 ] [ 0 ]
chave2 = str (1 )+str ( prox_salto2 )
porta_saida2 = s e l f . por tas . get ( chave2 )
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida2 ) )
core . openf low . getConnect ion (1 ) . send (msg)
def _handle_PacketIn ( s e l f , event ) :
packet = event . parsed
i f packet . type == packet .ARP_TYPE:
IP_ORIGEM = str ( packet . payload . p ro to s r c )
IP_DESTINO = str ( packet . payload . protodst )
else :
IP_ORIGEM = str ( packet . payload . s r c i p )
IP_DESTINO = str ( packet . payload . d s t i p )
PORTA_ORIGEM = None
PORTA_DESTINO = None
i f packet . payload . p ro to co l == packet . payload .TCP_PROTOCOL or packet .
payload . p ro to co l == packet . payload .UDP_PROTOCOL:
PORTA_ORIGEM = packet . payload . payload . s r cpo r t
PORTA_DESTINO = packet . payload . payload . ds tpor t
print "PORTA ORIGEM −−−−−−−" , PORTA_ORIGEM
print "PORTA DESTINO −−−−−−−−−" , PORTA_DESTINO
i f IP_DESTINO == " 1 0 . 0 . 0 . 3 " :
11.1 CÓDIGO DA APLICAÇÃO 61
#COMO EM PYTHON NAO EXISTE SWITCH CASE:
i f event . dpid == 1 :
prox_salto = s e l f . dij_1_melhor [ 5 ] [ 0 ]
chave = str (1 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
e l i f event . dpid == 2 :
prox_salto = s e l f . dij_2_melhor [ 5 ] [ 0 ]
chave = str (2 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
e l i f event . dpid == 3 :
prox_salto = s e l f . dij_3_melhor [ 5 ] [ 0 ]
chave = str (3 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
e l i f event . dpid == 4 :
prox_salto = s e l f . dij_4_melhor [ 5 ] [ 0 ]
chave = str (4 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
#ARP
i f packet . type == packet .ARP_TYPE:
msg = of . ofp_packet_out ( )
msg . bu f f e r_id = event . ofp . bu f f e r_id
i f event . dpid == 5 :
msg . a c t i on s . append ( o f . ofp_action_output ( port = 1) )
else :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )
event . connect ion . send (msg)
else :
i f s e l f .LINK_OK:
msg = of . ofp_flow_mod ( )
msg . match . dl_type = 0x800
msg . match . nw_proto = 17
msg . match . nw_dst = IPAddr ( " 1 0 . 0 . 0 . 3 " )
msg . match . tp_dst = PORTA_DESTINO
msg . id le_timeout = 10
11.1 CÓDIGO DA APLICAÇÃO 62
msg . hard_timeout = 60
msg . data = event . ofp
msg . buf f e r_id = event . ofp . bu f f e r_id
i f event . dpid == 5 :
msg . a c t i on s . append ( o f . ofp_action_output ( port = 1) )
else :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )
event . connect ion . send (msg)
else :
msg = o f . ofp_flow_mod ( )
msg . match . dl_type = 0x800
msg . match . nw_proto = 17
msg . match . nw_dst = IPAddr ( " 1 0 . 0 . 0 . 3 " )
msg . match . tp_dst = PORTA_DESTINO
msg . id le_timeout = 10
msg . hard_timeout = 60
msg . data = event . ofp
msg . buf f e r_id = event . ofp . bu f f e r_id
i f event . dpid == 5 :
msg . a c t i on s . append ( o f . ofp_action_output ( port = 1) )
else :
i f PORTA_DESTINO != 2000 :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )
else :
i f event . dpid == 1 :
prox_salto2 = s e l f . dij_1_segundo [ 5 ] [ 0 ]
chave2 = str (1 )+str ( prox_salto2 )
porta_saida2 = s e l f . por tas . get ( chave2 )
e l i f event . dpid == 2 :
chave2 = str (2 )+str (5 )
porta_saida2 = s e l f . por tas . get ( chave2 )
e l i f event . dpid == 3 :
chave2 = str (3 )+str (5 )
porta_saida2 = s e l f . por tas . get ( chave2 )
11.1 CÓDIGO DA APLICAÇÃO 63
e l i f event . dpid == 4 :
chave2 = str (4 )+str (5 )
porta_saida2 = s e l f . por tas . get ( chave2 )
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida2 )
)
event . connect ion . send (msg)
e l i f (IP_DESTINO == " 1 0 . 0 . 0 . 1 " or IP_DESTINO == " 1 0 . 0 . 0 . 2 " ) :
i f IP_DESTINO == " 1 0 . 0 . 0 . 1 " :
porta = 1
e l i f IP_DESTINO == " 1 0 . 0 . 0 . 2 " :
porta = 2
#COMO EM PYTHON NAO EXISTE SWITCH CASE:
i f event . dpid == 2 :
prox_salto = s e l f . dij_2_melhor [ 1 ] [ 0 ]
chave = str (2 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
e l i f event . dpid == 3 :
prox_salto = s e l f . dij_3_melhor [ 1 ] [ 0 ]
chave = str (3 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
e l i f event . dpid == 4 :
prox_salto = s e l f . dij_4_melhor [ 1 ] [ 0 ]
chave = str (4 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
e l i f event . dpid == 5 :
prox_salto = s e l f . dij_5_melhor [ 1 ] [ 0 ]
chave = str (5 )+str ( prox_salto )
porta_saida = s e l f . por tas . get ( chave )
#ARP
i f packet . type == packet .ARP_TYPE:
msg = of . ofp_packet_out ( )
msg . bu f f e r_id = event . ofp . bu f f e r_id
11.1 CÓDIGO DA APLICAÇÃO 64
i f event . dpid == 1 :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta ) )
else :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )
event . connect ion . send (msg)
else :
i f s e l f .LINK_OK:
msg = of . ofp_flow_mod ( )
msg . match . dl_type = 0x800
msg . match . nw_dst = IPAddr (IP_DESTINO)
msg . id le_timeout = 10
msg . hard_timeout = 30
msg . data = event . ofp
msg . buf f e r_id = event . ofp . bu f f e r_id
i f event . dpid == 1 :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta ) )
else :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )
event . connect ion . send (msg)
else :
msg = o f . ofp_flow_mod ( )
msg . match . dl_type = 0x800
msg . match . nw_dst = IPAddr (IP_DESTINO)
msg . match . nw_proto = 17
msg . match . tp_src = PORTA_ORIGEM
msg . id le_timeout = 10
msg . hard_timeout = 30
msg . data = event . ofp
msg . buf f e r_id = event . ofp . bu f f e r_id
i f event . dpid == 1 :
11.1 CÓDIGO DA APLICAÇÃO 65
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta ) )
else :
i f (PORTA_ORIGEM != 2000) :
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )
else :
i f event . dpid == 2 :
chave2 = str (2 )+str (1 )
porta_saida2 = s e l f . por tas . get ( chave2 )
e l i f event . dpid == 3 :
chave2 = str (3 )+str (1 )
porta_saida2 = s e l f . por tas . get ( chave2 )
e l i f event . dpid == 4 :
chave2 = str (4 )+str (1 )
porta_saida2 = s e l f . por tas . get ( chave2 )
e l i f event . dpid == 5 :
prox_salto2 = s e l f . dij_5_segundo [ 1 ] [ 0 ]
chave2 = str (5 )+str ( prox_salto2 )
porta_saida2 = s e l f . por tas . get ( chave2 )
msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida2 )
)
event . connect ion . send (msg)
def launch ( ) :
core . reg i s te rNew ( switch_multi )
Código 11.1: Código app.py em Python, aplicação que realiza a troca dinâmica das rotas
considerando a utilização do link principal
Referências bibliográ�cas
Cai et al. (2010) Zheng Cai, Alan L. Cox e T.S. Eugene Ng. Maestro: A system for scalableopen�ow control. Citado na(s) pág(s).: 32
Central () SDN Central. Documentation. http://www.sdncentral.com/. Último acesso emMaio/2014. Citado na(s) pág(s).:
Comer (2013) Douglas E. Comer. Internetworking with TCP/IP - Principals, Protocolsand Architecture. Pearson, 6 edição. ISBN 9780136085300. Citado na(s) pág(s).: 6, 9, 10, 11,13, 15, 16, 18, 19, 27
Erickson (2013) David Erickson. The beacon open�ow controller. Citado na(s) pág(s).: 32
Farrel (2004) Adrian Farrel. A Internet e seus protocolos. Campus Elsevier, 1 edição.ISBN 9788535266917. Citado na(s) pág(s).: 12
Feamster et al. (2014) Nick Feamster, Jennifer Rexford e Ellen Zegura. The road to sdn:An intellectual history of programmable networks. Citado na(s) pág(s).: 2, 18
Filho (2013) João Eriberto Mota Filho. Análise de tráfego em redes TCP/IP. Novatec, 1edição. ISBN 9788575223758. Citado na(s) pág(s).: 7
Foundation (2009) ONF Open Network Foundation. Open�ow switch speci�cation, ver-sion 1.0.0. Citado na(s) pág(s).: 24, 25, 26, 28
Foundation (2011a) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.1.0. Citado na(s) pág(s).: 29, 30
Foundation (2011b) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.2. Citado na(s) pág(s).: 30
Foundation (2012a) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.3.0. Citado na(s) pág(s).: 31
Foundation (2012b) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.4.0. Citado na(s) pág(s).: 31
Google (2012) Google. Inter-datacenter wan with centralized te using sdn and open�ow,2012. Citado na(s) pág(s).: 21
Gude et al. (2008) Natasha Gude, Ben Pfa�, Teemu Koponen, Martín Casado, ScottShenker, Justin Pettit e Nick McKeown. Nox: Towards an operating system for networks.Citado na(s) pág(s).: 32
66
11.1 REFERÊNCIAS BIBLIOGRÁFICAS 67
Handigol et al. (2012) Nikhil Handigol, Brandon Heller, Vimalkumar Jeyakumar, BobLantz e Nick McKeown. Reproducible network experiments using container-based emula-tion. Citado na(s) pág(s).: 35
Heller (2013) Brandon Heller. Reproducible Network Research with High-Fidelity Emula-tion. Tese de Doutorado. Citado na(s) pág(s).: 33, 35
http://archive.open�ow.org/wp/learnmore/ () http://archive.open�ow.org/wp/learnmore/.Documentation. http://archive.open�ow.org/wp/learnmore/. Último acesso em Maio de2014. Citado na(s) pág(s).:
https://open�ow.stanford.edu/display/ONL/POX+Wiki ()https://open�ow.stanford.edu/display/ONL/POX+Wiki. Pox wiki. https://open�ow.stanford.edu/display/ONL/POX+Wiki. Último acesso em Novembro de2014. Citado na(s) pág(s).:
http://trema.github.io/trema/ () http://trema.github.io/trema/. Trema. http://trema.github.io/trema/. Último acesso em Novembro de 2014. Citado na(s) pág(s).: 32
http://www.noxrepo.org/pox/about pox/ () http://www.noxrepo.org/pox/aboutpox/. About pox. http://www.noxrepo.org/pox/about-pox/. Último acesso em Novembrode 2014. Citado na(s) pág(s).: 32
iperf.fr () iperf.fr. Documentation. http://iperf.fr/. Último acesso em Maio/2014. Citado
na(s) pág(s).: 40
Kurose e Ross (2010) James F. Kurose e Keith W. Ross. Redes de Computadores e aInternet: Uma abordagem top-down. Pearson, 5 edição. ISBN 9788588639973. Citado na(s)
pág(s).:
Lantz e O'Connor () Bob Lantz e Brian O'Connor. Mininet: An instant virtual networkon your laptop. Citado na(s) pág(s).: 33, 34
Lantz et al. (2010) Bob Lantz, Brandon Heller e Nick McKeown. A network in a laptop:Rapid prototyping for software-de�ned networks. Citado na(s) pág(s).: 33, 35
Lara et al. (2014) Adrian Lara, Anisha Kolasani e Byrav Ramamurthy. Network innovationusing open�ow: A survey. Citado na(s) pág(s).: 22, 30
McKeown (2011) Nick McKeown. How sdn will shape networking, 2011. Citado na(s) pág(s).:
20
McKeown et al. (2008) Nick McKeown, Guru Parulkar, Tom Anderson, Larry Peterson,Scott Shenker, Jonathan Turner, Hari Balakrishnan e Jennifer Rexford. Open�ow: Ena-bling innovation in campus networks. Citado na(s) pág(s).: 2, 23
mininet.org () mininet.org. Documentation. http://mininet.org/. Último acesso em Maiode 2014. Citado na(s) pág(s).:
Nunes et al. (2014) Bruno Astuto A. Nunes, Marc Mendonça, Xuan-Nam Nguyen, KatiaObraczka e Thierry Turletti. A survey of software-de�ned networking: Past, present adfuture of programmable networks. Citado na(s) pág(s).: 17, 19, 32
Opennetworking () Opennetworking. Documentation. https://www.opennetworking.org/. Último acesso em Maio/2014. Citado na(s) pág(s).:
11.1 REFERÊNCIAS BIBLIOGRÁFICAS 68
Postel (1981) Jon Postel. Rfc 791 - internet protocol, 1981. Citado na(s) pág(s).:
Tanenbaum (2012) Andrew Stuart Tanenbaum. Redes de computadores. Pearson, 5 edição.ISBN 978876059240. Citado na(s) pág(s).:
Wikipédia () Wikipédia. Software-de�ned networking. http://en.wikipedia.org/wiki/Software-de�ned_networking. Último acesso em Maio/2014. Citado na(s) pág(s).:
Yamamoto e Scharra (2014) Kazuo Yamamoto e Marcus Scharra. Fundamentals of sdnin the enterprise - basic concepts and use cases. http://www.cisco.com/web/BR/eventos/quintas_quinze.html, 2014. Último acesso em Novembro de 2014. Citado na(s) pág(s).: 21
Top Related