Desenvolvimento de Uma Aplicação para Diferenciação de Caminhos em Redes Definidas Por Software

Elton Gastardelli Kleis
Desenvolvimento de uma aplicao

para diferenciao de caminhos em redes
definidas por software
Niteri, 2 de dezembro de 2014

Trabalho
apresentado
Engenharia
de
Universidade
UFF,
como
Curso
de
Telecomunicaes
da
Federal
requisito
ao
Fluminense
para
obteno
do ttulo de Bacharel em Engenharia

de Telecomunicaes.
Orientadora:
Prof.
Castro Fernandes
Dra.
Natalia

Trabalho apresentado ao Curso de
Engenharia de Telecomunicaes da
Universidade Federal Fluminense UFF, como requisito para obteno
do ttulo de Bacharel em Engenharia
de Telecomunicaes.
Aprovado em: 10 de Dezembro de 2014
Comisso julgadora:
Prof. Dr. Ricardo Campanha Carrano
Prof. Dr. Joo Marcos Meirelles da Silva
Prof. Dra. Natalia Castro Fernandes

Agradecimentos
Primeiramente gostaria de agradecer minha famlia, meu pai Samuel, meu irmo
Natan e principalmente minha me 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 tambm a minha namorada Patricia, que desde o ensino mdio 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. Agradeo tambm ao
professor Mrcio Albuquerque (CBPF) por todo o apoio e conselhos e ao Lus Henrique
Rosati Rocha (BNDES) pelo exemplo de carter e prossionalismo. Agradeo a todos meus
amigos que direta ou indiretamente contriburam para minha formao, principalmente ao
Alan Henrique Ferreira, Gabriel Oliveira e ao Rogrio Libarino. A todos vocs, meu muito
obrigado!
Resumo
Nessa monograa, apresentado um novo paradigma em redes de computadores, as redes
denidas por software.
Esse conceito surgiu em universidades americanas em meados de 2008 e prope a retirada
da inteligncia dos dispositivos de redes como switches e roteadores. Essa inteligncia
seria concentrada em um controlador, entidade com total viso e controle da rede.
Em redes denidas por software, tm-se uma maior exibilidade, j que se pode criar
diversas aplicaes, programando o controlador da rede. Aplicaes que hoje seriam impensveis comearo a ser desenvolvidas com facilidade. Diante desse novo paradigma em redes de
computadores, uma aplicao simples desenvolvida em Python apresentada. Essa aplicao
altera o caminho de um determinado uxo mediante a uma circunstncia pr-estabelecida.
A mesma foi testada utilizando o emulador Mininet e alguns resultados de desempenho
so apresentados.
Palavras-chave: SDN, Redes denidas por software, Redes programveis, POX, Mininet.
ii
Abstract
In this monograph, a new computer networks' paradigm is presented, Software-Dened
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-Dene 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 specic 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-Dened Networking, Programmable Networks, POX, Mininet
iii
Lista de guras
2.1
As quatro camadas do modelo TCP/IP. . . . . . . . . . . . . . . . . . . . . .
2.2
Em (a) tem-se a viso do usurio da rede e em (b) a estrutura fsica com os

enlaces e roteadores representados.
. . . . . . . . . . . . . . . . . . . . . . .
2.3
Cabealho do protocolo IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
Algoritmo executado pelo roteador ao receber um pacote
2.5
Ilustrao do aprendizado de rotas pelo roteador e distino entre as bases de

informaes de roteamento e de encaminhamento
2.6
. . . . . . . . . . .
. . . . . . . . . . . . . . .
10
12
Em (a), tabela de encaminhamento presente no roteador `Y. (b) ilustra uma

mensagem de atualizao do roteador X que ir causar mudanas em Y
13
2.7
Troca de rtulos realizada por cada dispositivo . . . . . . . . . . . . . . . . .
15
3.1
Planos de controle e dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Congurao bsica SDN, com um controlador externo congurando o dispositivo de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3
Representao de uma rede genrica.
. . . . . . . . . . . . . . . . . . . . . .
20
4.1
Switch OpenFlow idealizado. . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
Entrada da tabela de uxos. . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Campos de cabealho.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.4
Lista dos contadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.5
Fluxograma do processamento dos pacotes. . . . . . . . . . . . . . . . . . . .
26
4.6
Tipos de mensagens para modicao da tabela de uxos.
. . . . . . . . . .
28
4.7
Componentes de um switch OpenFlow 1.1
. . . . . . . . . . . . . . . . . . .
29
4.8
Fluxograma detalhando o uxo de pacotes atravs 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
Virtualizao completa dos dispositivos.
. . . . . . . . . . . . . . . . . . . .
34
5.3
Virtualizao "leve"dos dispositivos. . . . . . . . . . . . . . . . . . . . . . . .
34
6.1
Pacotes LLDP.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
6.2
Fluxograma representando primeira etapa da execuo da aplicao. . . . . .
37
6.3
Pacotes ARP e respota do controlador. . . . . . . . . . . . . . . . . . . . . .
37
iv
LISTA DE FIGURAS
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
Inicializao do Mininet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
7.3
Inicializao da aplicao.
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
7.9
pelo melhor caminho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Teste com dois hosts enviando pelo mesmo caminho.
44
. . . . . . . . . . . . .
7.10 Percentual da perda dos pacotes, realizando a mudana de rota dinamicamente. 45

7.11 Resultado do primeiro teste. . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
7.12 Tabela de uxos do switch 1. . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
7.13 Percentual mdio dos erros . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
7.14 Taxa de transmisso mdia . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Lista de acrnimos
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-Dened 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
Sumrio
Lista de guras
iv
1 Introduo
1.1
Motivao e objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Organizao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Conceitos bsicos das redes de computadores

2.1
Modelo em camadas
2.2
Endereamento
2.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mscara de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Encaminhamento
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4.1
Protocolos do tipo vetor distncia . . . . . . . . . . . . . . . . . . . .
12
2.4.2
Protocolos do tipo estado de enlace . . . . . . . . . . . . . . . . . . .
14
2.5
Comutao baseada em rtulos
. . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5.1
. . . . . . . . . . . . . . . . . . . . . . . . .
16
Classicao de pacotes
3 SDN - Redes Denidas por Software

3.1
Engenharia de Trfego
3.2
Um novo paradigma em redes de computadores
17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
4 OpenFlow
17
18
22
4.1
Composio dos switches OpenFlow . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
Tabela de uxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
O canal seguro
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.4
Outras verses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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
POX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.5
5 Mininet
33
vii
SUMRIO
6 A aplicao desenvolvida
6.1
36
Executando a aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Simulao e resultados
7.1
viii
36
40
Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
8 Concluses
48
9 Apndice A
50
9.1
Cdigo para criao da topologia
. . . . . . . . . . . . . . . . . . . . . . . .
10 Apndice B
10.1 Cdigo para calcular as rotas
52
. . . . . . . . . . . . . . . . . . . . . . . . . .
11 Apndice C
11.1 Cdigo da aplicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Referncias bibliogrcas
50
52
56
56
66
Captulo 1
Introduo
As redes de computadores nos permitem fazer coisas inimaginveis h poucas dcadas.
Seu embrio teve incio no nal da dcada de 1960 com a ento denominada ARPANET
Advanced Research Projects Agency Network ),
que buscava interligar as bases militares e
os departamentos de pesquisa norte americanos. Muito evolui desde ento. Modelos para
protocolos de comunicao foram criados e muitos protocolos foram desenvolvidos, sejam
para suprir a demanda de aplicaes, sejam para calcular os caminhos que os pacotes devem
percorrer ao longo da rede.
Devido essa evoluo de ideias, desde o incio das pesquisas sobre comutao de pacotes
e da ARPANET, juntamente com a evoluo do hardware utilizado, hoje temos inmeras
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 ligaes telefnicas
atravs da Internet.
Entretanto, talvez hoje as redes estejam na iminncia de uma mudana de paradigma,
mudana essa que possibilitar o desenvolvimento de aplicaes cuja implementao com
a tecnologia atual seria impossvel. Com a utilizao de redes denidas por software (SDN
-
Software-Dened Networking ),
ser possvel um total controle da rede. No haver mais
a necessidade de hardwares especializados, mas sim, poder se utilizar hardwares genricos

programveis. Novos protocolos podero ser testados e implementados com uma rapidez
nunca antes vista e aplicaes que hoje so impensveis se tornaro absolutamente viveis
atravs da implementao dessa tecnologia.
MOTIVAO E OBJETIVOS
1.1
1.1 Motivao e objetivos

Atualmente, as redes de computadores se tornaram parte essencial da infraestrutura
de nossa sociedade. Hoje, inmeras aplicaes rodam sobre a Internet, aplicaes essas
que no foram imaginadas no projeto inicial das redes de computadores. Com o objetivo de
suportar o nmero crescente de aplicaes e usurios, diversos remendos foram sendo feitos
ao longo dos anos. Entretanto, substancialmente, o ncleo da rede se manteve o mesmo. Os
softwares de switches e roteadores no podem ser reprogramados e novas ideias e protocolos
no podem ser testados em uma rede em produo, fato esse denominado por alguns autores
como ossicao da rede (McKeown
et al. , 2008). Nesse cenrio, surgem as redes denidas
por software.
O conceito de redes programveis no novo. Como exemplo, tem-se o conceito de redes
ativas na dcada de 1990 (Feamster
et al. , 2014). Entretanto, pela primeira vez, o conceito
amplamente difundido e aceito. As redes denidas por software vm apresentando grande

aceitao por parte da comunidade acadmica e pelos principais fabricantes de equipamentos,
que j comearam a desenvolver solues voltadas para esse modelo.
Diante o exposto, como objetivo geral, essa monograa pretende apresentar ao leitor
esse novo paradigma em redes de computadores, mostrando o quo 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 especcos devem ser atingidos:
Apresentao dos conceitos bsicos das redes de computadores atuais, fornecendo um

conhecimento mnimo para aqueles que no estejam familiarizados com redes de computadores;
Abordar conceitos como plano de controle e de dados, e sua separao nas redes denidas por software;
Apresentar conceitos do OpenFlow, implementao mais difundida das redes denidas

por software;
Apresentao de uma aplicao programada em Python, para redes denidas por software. Essa aplicao altera o caminho de um uxo pr-estabelecido, mediante a uma
alta utilizao da largura de banda do caminho principal;
ORGANIZAO DO TRABALHO
1.2
1.2 Organizao do trabalho

Essa monograa est estruturada como mostrado a seguir.
No Captulo 2, sero apresentados conceitos de redes de computadores bsicos para que
seja possvel o entendimento posterior das redes denidas por software. O mesmo tratar de
assuntos como o modelo de camadas TCP/IP, endereamento, encaminhamento de pacotes
e comutao baseada em rtulos.
O Captulo 3 tratar dos conceitos bsicos sobre planos de controle e de dados e, sequencialmente, da denio de redes denidas por software.
No Captulo 4, ser apresentado o padro/protocolo OpenFlow. Os switches OpenFlow
sero denidos e suas caractersticas como tabela de uxos e o canal seguro sero explanadas. Tambm so apresentados nesse captulo os principais controladores disponveis, dando
enfoque ao POX, controlador utilizado.
O Mininet, emulador de redes utilizado nesse trabalho, apresentado e suas caractersticas explicadas no Captulo 5.
No Captulo 6 uma descrio detalhada da aplicao desenvolvida ser apresentada. J
no Captulo 7 so apresentados os resultados dos testes feitos, vericando como o uso da
aplicao reduziu a perda de pacotes.
As concluses so apresentadas no Captulo 8 e nos captulos seguintes os cdigos utilizados para o experimento podem ser encontrados.
Captulo 2
Conceitos bsicos das redes de
computadores
Nesse captulo, sero abordados conceitos como modelo de camadas TCP/IP, endereamento, encaminhamento e classicao de pacotes. Conceitos esses fundamentais para o
pleno entendimento das vantagens e desvantagens das redes denidas 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 comunicao entre dispositivos. Esses protocolos so organizados de acordo

com uma pilha de camadas, onde cada camada ir oferecer servios para as camadas superiores. Essa diviso em camadas, ao reduzir a complexidade, facilita a implementao de novas
tecnologias, permitindo tambm 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.
MODELO EM CAMADAS
2.1
Na camada de aplicao, o nvel mais alto do modelo, usurios utilizam programas que
acessam servios disponveis atravs da rede TCP/IP. A aplicao ir interagir com protocolos 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 usurio
nal, ou seja, o mesmo no precisa ter conhecimento sobre a implementao das camadas
subjacentes.
A principal funo da camada de transporte prover uma comunicao ponto-a-ponto,
ou seja, conectando uma aplicao de um dispositivo origem com uma aplicao em um
dispositivo destino, independentemente da quantidade de equipamentos intermedirios. Com
isso, a camada transporte deve aceitar dados provenientes de diversas aplicaes, encapsullos, incluindo informaes que sero utilizadas para controle e para identicao da aplicao
de origem e destino e enviar esses dados encapsulados para as camadas mais baixas.
A camada de transporte pode tambm regular o uxo de informaes, podendo inclusive
oferecer um transporte convel, como por exemplo, vericando periodicamente a conexo
estabelecida e assegurando que os dados esto sendo enviados e recebidos corretamente,
Datagram Protocol )
chegando sem erros. So exemplos de protocolos dessa camada, o UDP (

e o TCP.
A camada de internet lida com a comunicao 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 cabealho com diversas informaes,
inclusive com o endereo lgico de origem (IP de origem) e o endereo lgico de destino (IP
de destino).
A camada de internet tambm responsvel por encaminhar esses pacotes para a camada
de acesso rede, onde os mesmos sero encaminhados diretamente para o destino (podendo
vir a passar por dispositivos como switches e hubs), se os hosts estiverem na mesma rede.
Caso no estejam, como duas redes diferentes no se enxergam os pacotes devem ser
enviados para equipamentos que fazem a interligao entre redes, denominados roteadores.
Atravs dos roteadores os pacotes podem ser encaminhados por redes intermedirias, at
chegarem ao destino nal. A camada de internet tambm responsvel por lidar com os
pacotes IP's recebidos, checando sua validade e vericando se os mesmos so destinados para
um host na rede local ou se devem ser encaminhados para outras redes. Maiores detalhes
sobre a camada de rede sero vistos na seo sobre encaminhamento.
A camada de acesso rede dene as regras de acesso ao meio fsico denindo o endereamento fsico e os protocolos necessrios para essa transmisso. Alm disso, converte os
dados vindos da camada superior (internet) em sinais eltricos/pticos, tornando possvel a
transmisso em cabos e bras pticas.
importante entender que para a camada de internet no importa a localizao fsica das
mquinas, mas a localizao lgica das redes. A camada de acesso rede, responsvel pela
Address
identicao de cada mquina (endereamento fsico) em uma rede local. O ARP (
Resolution Protocol ), protocolo da camada de rede, far a traduo do endereo lgico para
ENDEREAMENTO
2.2
o endereo fsico, quando o pacote de dados j estiver na rede de destino.

Para nalizar, as redes em camadas so projetadas de modo que uma determinada camada no destino receba exatamente os mesmos objetos enviados pela mesma camada correspondente na origem, ou seja, os mesmos dados enviados pela camada de aplicao na
origem, devem ser os mesmos dados recebidos pela camada de aplicao no destino.
As redes de computadores em geral, sobretudo a Internet, foram projetadas para prover
uma interconexo universal entre computadores independentemente das particularidades da
rede aos quais estejam conectados, tornando-se transparente para o usurio, que a v como
uma nica rede virtual (como pode ser visto na Figura 2.2), a qual todas as mquinas esto
conectadas. Essa virtualizao ser importante para o entendimento das redes denidas por
software.
Figura 2.2: Em (a) tem-se a viso do usurio da rede e em (b) a estrutura fsica com os enlaces
e roteadores representados.
Fonte: Comer (2013)
2.2 Endereamento
Sendo a camada de internet uma das mais importantes do modelo TCP/IP, torna-se
interessante o entendimento da diviso e endereamento lgicos dos dispositivos, assim como
tambm interessante entender como ocorre o roteamento e encaminhamento dos pacotes.
Em uma rede TCP/IP, cada adaptador de rede existente em um dispositivo identicado
por um nmero chamado endereo IP. Tomando-se como base o IP verso 4, esse endereo IP
consiste em quatro conjuntos de 8 bits. Esses octetos, quando representados, so separados
por pontos.
ENDEREAMENTO
2.2
Um exemplo de endereo IP segue abaixo:

00001010.00000000.00000000.00000001
Dessa forma, todos os 32 bits so representados. Entretanto, a forma mais usual de
representao do endereo IP, a decimal. O mesmo endereo IP representado acima, pode
ser escrito como:
10.0.0.1
Dito isso, pode-se concluir que o menor octeto possvel o 00000000 (0 em decimal) e o
maior octeto possvel o 11111111 (255 em decimal), ou seja, cada octeto pode variar de 0
a 255.
Parte do endereo 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 Mscara de rede

A mscara de rede um recurso utilizado para segmentar redes logicamente. Com esse
recurso, pode-se ter vrias redes lgicas diferentes disponveis no mesmo espao fsico, ou
ainda, pode-se ter uma nica rede lgica em mais de uma localidade fsica.
Essa rede lgica pode ser entendida como conjuntos independentes de dispositivos (computadores, impressoras, switches) conectados rede em um determinado espao fsico. As
divises em redes lgicas diferentes so feitas justamente com base no endereo IP e na
mscara de rede.
A mscara de rede denida como um conjunto de 32 bits divididos em quatro octetos,
assim como o endereo IP. Entretanto, algumas regras so levadas em considerao na criao
da mscara de rede Filho
(2013):
No pode haver a mistura de algarismos 0 e 1;
No pode haver algarismo 0 antes de algarismo 1;
Segue abaixo um exemplo de mscara de rede, com os bits representados e tambm na

forma decimal:
11111111.00000000.00000000.00000000
255.0.0.0
Essa mscara de rede ser comparada com o endereo IP. Os bits que forem 1 na mscara
de rede representam a poro da rede no endereo IP e os bits que forem 0 representam o
dispositivo.
Logo, pegando-se o endereo IP do exemplo acima e analisando-o com o exemplo de
mscara de rede, tem-se que os oito primeiros bits do endereo IP so referentes rede, ou
seja, o valor 10. J os .0.0.1 representam o dispositivo dessa rede.
A notao usual, a notao CIDR (
Classless Inter-Domain Routing ), a representao
do endereo IP, seguido de uma barra (/) e da quantidade de bits que so correspondentes
poro de rede.
ENCAMINHAMENTO
2.3
Logo, como foram utilizados oito bits para a mscara de rede acima, temos a seguinte
notao:
10.0.0.1/8
Um outro exemplo segue abaixo:
IP : 11000000.10101000.00000000.00000001 = 192.168.0.1
Mscara: 11111111.11111111.11111111.00000000 = 255.255.255.0
Notao CIDR: 192.168.0.1/24
Logo, os 24 primeiros bits representam a poro do IP destinado rede e os ltimos 8 bits
representam o dispositivo daquela rede. Para representar o endereo de rede, completa-se a
parte do endereo IP referente ao dispositivo com bits zero.
Logo para os dois exemplos apresentados tm-se as redes:
10.0.0.0/8
192.168.0.0/24
Os conceitos de mscaras de rede e de endereo de rede so importantes, pois os mesmos
sero utilizados nos roteadores para a realizao 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 servios que a camada de
internet pode oferecer.
A camada de internet oferece dois tipos distintos de servios. O servio orientado a
conexo e o servio no orientado a conexo. As redes orientadas a conexes so denominadas
redes de circuitos virtuais. Como exemplos, tm-se as redes ATM (
Mode )
Frame Relay.
Asynchronous Transfer
J a Internet uma rede de datagramas, ou seja, uma rede no
orientada a conexes. Nesse trabalho, quando no especicado o contrrio, o texto estar

tratando das redes no orientadas a conexes.
O servio de entregas oferecido pela camada de rede em uma rede de datagramas, como
a Internet, pode ser denido como incerto, de melhor esforo (
best-eort ) e com entrega de
pacotes sem conexo.

O servio incerto, pois a entrega de pacotes no garantida. Os pacotes podem ser
perdidos, duplicados, podem chegar atrasados ou at mesmo fora de ordem. O servio dito
de melhor esforo, porque os pacotes tentaro ser entregues, entretanto no h garantias.
No h garantia de largura de banda e nem mesmo indicaes de congestionamento.
Finalmente o servio tambm denido como sem conexo, pois cada pacote tratado
independentemente. Uma sequncia de pacotes enviados de um dispositivo a outro, podem
trafegar por diferentes caminhos. No existe um circuito pr-denido como existe, por exemplo, nas redes de circuitos virtuais. Uma exceo seria a tecnologia MPLS (
Multiprotocol Label
ENCAMINHAMENTO
2.3
Switching ) que ser abordada posteriormente.

O protocolo IP, um dos mais importantes do modelo TCP/IP, apresenta todas as caractersticas supracitadas e ainda:
Dene a unidade bsica de dados que ser transmitida atravs da rede TCP/IP, especicando o formato dos pacotes utilizados por todos os dados.
O IP dene uma srie de regras, como por exemplo, como dispositivos e roteadores devem processar os pacotes e as condies sob as quais os pacotes podem ser descartados.
Comer
(2013)
Apenas a ttulo de ilustrao, segue na Figura 2.3 o formato do cabealho IPv4.
Figura 2.3: Cabealho do protocolo IPv4
Fonte: RFC 791

Conforme dito anteriormente, a transmisso de datagramas IP entre dois dispositivos em
uma nica rede fsica, no envolver o uso de roteadores. O dispositivo que est enviando
os dados encapsular o datagrama em um quadro, vincular o endereo do prximo salto ao
endereo fsico do dispositivo de destino e enviar o quadro resultante para o dispositivo de
prximo salto.
Caso o dispositivo no esteja na mesma rede, o protocolo selecionar o prximo 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 endereo IP dividido
em duas partes, uma que ir identicar a rede e outra que ir identicar o dispositivo.
Logo, ao receber o quadro, o roteador desencapsula o pacote e compara os bits referentes
identicao da rede do endereo IP do dispositivo destino com o endereo de rede dos
endereos IP's de suas interfaces. Uma equivalncia signica que o dispositivo destino se
encontra na rede ligada a essa interface. Esse teste computacionalmente eciente, pois
requer apenas algumas instrues de mquina.
O encaminhamento dos pacotes do tipo prximo salto, ou seja, o roteador que acabou
de receber o pacote, no precisa saber quais so todos os saltos intermedirios que o pacote
ENCAMINHAMENTO
2.3
10
dever percorrer at chegar ao destino. Precisa saber apenas qual o prximo salto, e para
isso, o mesmo ir vericar sua tabela de encaminhamento (FIB -
base ).
Forwarding information
Se todos os roteadores da internet precisassem ter em suas tabelas de encaminhamento

todos os IP's disponveis, os mesmo precisariam de uma enorme quantidade de memria alm
de que, a cada alterao de rota os roteadores precisariam reescrever inmeras entradas.
Entretanto, as tabelas de encaminhamento precisam conter apenas o endereo das redes, ou
seja, o prexo das redes dos endereos IP.
Ento, uma tabela de encaminhamento ter, conceitualmente, um conjunto de pares
(P,R) onde P o prexo da rede e R, o endereo IP do prximo 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 informaes na
FIB, escolher as melhores rotas de acordo com a utilizao corrente do link, pelo tamanho
do datagrama, tipo de dados que esto sendo transportados ou ainda de acordo com o
custo dos links. Entretanto, ser visto que a maioria dos protocolos de roteamento so bem
menos sosticados, selecionando rotas baseadas em dados xos sobre menores caminhos.
Fato que interessante ressaltar, j que nas redes denidas por software, novos protocolos de
roteamento com as mais diversas mtricas podero ser implementados facilmente, tornando
o encaminhamento mais inteligente e robusto.
Voltando-se ao encaminhamento de pacotes, o algoritmo realizado pelo roteador ao receber 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)
ROTEAMENTO
2.4
11
Entretanto, para o algoritmo acima funcionar corretamente, algumas condies precisam

ser pr-denidas.
Primeiramente, diferentemente do modelo conceitual de tabelas de encaminhamento, a
tabela precisa conter o IP da sub-rede de destino que ser comparado, a mscara de rede, o
IP do prximo roteador e a interface para onde devem ser enviados os pacotes. A interface
tambm 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 mscara de rede maior (rotas mais especcas) devem ser vericadas
antes das rotas mais genricas. Comer (2013)
O encaminhamento, como foi visto, uma das principais funes do protocolo IP e dos
roteadores. O mesmo no poderia atualmente ser executado corretamente, se no existissem
os protocolos de roteamento. Como ser visto a seguir, as entradas na tabela de encaminhamento poderiam at ser conguradas manualmente, mas essa ao com as redes de
computadores atuais, principalmente a Internet, se tornaria impraticvel.
2.4 Roteamento
Na seo anterior, foi visto o encaminhamento desempenhado pelo IP, onde dado um
determinado pacote IP, feita a vericao do prximo salto na tabela de encaminhamento
e o direcionamento desse pacote para o mesmo.
As rotas da tabela de encaminhamento podem ser originadas basicamente de trs formas.
A primeira so as rotas diretas. So as redes as quais o roteador se conecta diretamente. A
segunda a forma esttica, onde o gestor da rede precisa congurar cada rota manualmente.
Pode ser utilizada em pequenas redes domsticas, entretanto em redes mais complexas, onde
existiro diversos roteadores organizados em uma malha, existindo diversos enlaces entre eles,
essa congurao manual torna-se muito onerosa. A congurao das rotas manualmente
tambm torna-se um problema devido necessidade de reagir dinamicamente s mudanas
da rede, como por exemplo devido falhas de um enlace ou ainda quando novos roteadores
so acrescentados.
J na terceira forma, chamada de roteamento dinmico, as rotas sero conguradas
automaticamente, de acordo com os protocolos de roteamento e como ser visto, existem
basicamente dois tipos predominantes, os protocolos do tipo vetor distncia e do tipo estado
de enlace.
Antes de vericar-se o roteamento dinmico, torna-se interessante a distino de protocolos IGP (
Interior Gateway Protocol )
e EGP (
Exterior Gateway Protocol ).
A Internet,
como sabido, uma rede de redes de computadores. Cada agrupamento organizacional

denido como um sistema autnomo (AS -
Autonomous System ),
sistema esse que pode
operar isoladamente de todos os outros agrupamentos. Logo, nem todas as informaes de
ROTEAMENTO
2.4
12
roteamento que so trafegadas internamente dentro de um AS devem ser compartilhadas com

outros AS's, j que no interessante a divulgao de detalhes internos do mesmo. Com isso,
tm-se os protocolos que distribuem informaes de roteamento dentro dos AS's, chamados
de IGP's e os protocolos EGP's, protocolos de roteamento que distribuem informaes entre
AS's. Farrel (2004)
A Figura 2.5 ilustra o aprendizado das rotas pelo rotador.
Figura 2.5: Ilustrao do aprendizado de rotas pelo roteador e distino entre as bases de infor-
maes de roteamento e de encaminhamento
Fonte: Farrel
(2004)
As rotas provenientes a partir dos protocolos de roteamento so combinadas com as rotas

estticas conguradas e com as rotas diretas descobertas, dando origem a RIB (
Information Base ).
Routing
A RIB apresenta diversas informaes sobre as rotas disponveis na rede. Parte dessa
informao pode sugerir vrias rotas para um nico destino, e um mecanismo de deciso de
roteamento aplica polticas de roteamento para determinar as melhores rotas. A RIB dar
origem a FIB. A FIB oferece informaes no ambguas ao componente do roteador que
encaminha os pacotes de dados.
2.4.1 Protocolos do tipo vetor distncia

A ideia dos protocolos dessa modalidade bastante simples. Cada roteador mantm uma
lista de todos os destinos alcanveis da rede e distribui essa lista de tempos em tempos
para seus vizinhos.
ROTEAMENTO
2.4
13
Cada entrada na tabela de roteamento identicar a rede de destino, o roteador usado

para o prximo salto e a distncia at a rede de destino. Essa distncia geralmente ser
hops ) at o destino. Por exemplo, uma rede diretamente conectada
a quantidade de saltos (
estar a zero saltos de distncia. Se um datagrama precisa passar por N roteadores para
chegar ao destino, o destino est a N saltos de distncia.
Quando um roteador novo X inserido, primeiramente ele ir se anunciar aos vizinhos.
Os vizinhos propagaro a informao dizendo que podem chegar at X com um salto de
distncia e assim sucessivamente.
Quando uma mensagem, por exemplo, proveniente de X, chega em Y, Y tomar as
seguintes aes:
Se X conhece um destino que Y no, Y ir adicionar esse destino a sua tabela de
roteamento, congurando como prximo 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, congurando o prximo salto para X e corrigindo o custo;
Se a entrada para um determinado destino j existe em Y, sendo o prximo 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 atualizao do roteador X que ir causar mudanas em Y
Fonte: Imagem baseada em Comer (2013)
Essa modalidade de protocolos, torna-se ideal para redes pequenas a mdias, uma vez
que a transmisso de toda a tabela de roteamento para cada vizinho lenta e a ocorrncia de
perdas pode causar loops, demandando um longo tempo para a convergncia das informaes.
Como vantagens, tm-se a baixa complexidade de implementao e os baixos requisitos de
processamento e memria.
Routing
Como exemplos de protocolos do tipo vetor distncia, tm-se os protocolos RIP (
Information Protocol ) e EIGRP (Enhanced Interior Gateway Routing Protocol ).
ROTEAMENTO
2.5
14
2.4.2 Protocolos do tipo estado de enlace

Diferentemente dos protocolos do tipo vetor distncia, os protocolos do tipo estado de
enlace no iro distribuir uma lista de rotas, informando os custos e os destinos que o mesmo
pode atingir.
Os roteadores caro, periodicamente, testando os status das conexes com seus vizinhos, realizando a troca de pequenas mensagens para constatar se o vizinho est ativo e
atingvel. Caso o vizinho responda a mensagem, o link estar
ser considerado
down.
up,
caso negativo, o mesmo
Aps a descoberta dos vizinhos, o roteador envia periodicamente mensagens para informar 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 no especicam rotas, informam apenas
se a comunicao possvel entre o par de roteadores referidos na mensagem.
Esse processo de inundao das mensagens simples. O roteador recebe um LSP e verica
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 no conhea, 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, aps a rede convergir, cada roteador possuir um mapa completo e idntico da
rede.
Para calcular as rotas entre os enlaces disponveis 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.
Open Shortest Path
Um dos protocolos de estado de enlace mais conhecidos, o OSPF (
First ),
tm uma mtrica padro proporcional largura de banda dos enlaces. Com isso,
o melhor caminho sempre ser o mais rpido, ao contrrio do vetor distncia, que usa o
caminho com menor nmero de saltos.
Uma outra vantagem dos protocolos de estado de enlace que cada roteador realiza
os clculos das rotas independentemente, usando os mesmos dados de status originais, no
dependendo de roteadores intermedirios como o vetor distncia. Esse tipo de protocolo
ideal para redes grandes, pois sua percepo de problemas ou de novos roteadores e a
consequente propagao dessas informaes so rpidas. Mas, como desvantagem, o clculo
das alteraes nas tabelas de roteamento exige bastante processamento.
So exemplos de protocolos o OSPF e o IS-IS.
Nessa seo, termina-se uma breve introduo ao funcionamento das redes de computadores atuais. A prxima seo, tem como objetivo apresentar a comutao baseada em
rtulos, que ser a base da tecnologia MPLS. Devido exibilidade de roteamento existente
em tal tecnologia, torna-se interessante a citao da mesma, para posterior compreenso das
redes denidas por software.
COMUTAO BASEADA EM RTULOS
2.5
15
2.5 Comutao baseada em rtulos

A comutao baseada em rtulos o processo de encaminhar pacotes de dados dentro
da rede, baseado em algum rtulo associado com cada pacote. Essa ideia surgiu em meados
da dcada de 1980, com o objetivo de melhorar o desempenho na transmisso de pacotes.
A tecnologia nos comutadores explora o indexamento para atingir velocidades extremamente altas no encaminhamento de dados. Para isso, cada pacote carrega um nmero inteiro
conhecido como rtulo. Quando um pacote chega no comutador, o comutador extrai o rtulo
e usa o valor como ndice na tabela que ir especicar a ao apropriada. Cada comutador
pode ter uma srie de interfaces de sada e a ao geralmente consiste em enviar o pacote
por uma dessas interfaces.
A comutao baseada em rtulos, apresenta como grande vantagem a exibilidade em
roteamento. Nem sempre desejvel que todos os dados para um mesmo destino sejam roteados pelo mesmo caminho. Pode ser desejado que um trfego de maior prioridade percorra
um caminho mais curto, enquanto que os trfegos de menor prioridade, podem ser enviados
por caminhos mais longos. A maioria das tcnicas de roteamento como foi visto, costuma
enviar o trfego para o caminho mais curto.
Como citado, comutao de rtulos consiste em associar um rtulo pequeno e de formato
xo em cada pacote de dados de modo que ele possa ser encaminhado na rede. Isso signica
que cada pacote, precisa transportar um identicador que ir dizer aos ns da rede como
encaminh-lo. Em cada salto por meio da rede, o pacote encaminhado com base no valor
do rtulo que chega e encaminhado com um novo valor de rtulo. A Figura 2.7 ilustra essa
troca de rtulos e o encaminhamento dos pacotes.
Figura 2.7: Troca de rtulos realizada por cada dispositivo
Fonte: Comer (2013)
At o momento, a comutao baseada em rtulos foi descrita como uma tecnologia de

rede orientada para conexes de propsito geral. Ser apresentado agora, como a comuta-
Internet
o baseada em rtulos pode ser combinada com a Internet. Em 1991, a IETF (
Engineering Task Force ) padronizou atravs da RFC 3031 o MPLS.
COMUTAO BASEADA EM RTULOS
2.5
16
O protocolo utiliza a comutao baseada em rtulos, explicada anteriormente e como o

prprio nome sugere, o mesmo foi projetado para transportar quaisquer
payloads. Na prtica,
o MPLS usado quase que exclusivamente para transportar pacotes IP.

Geralmente o MPLS utilizado no ncleo de grandes ISP's (
Internet Service Providers ).
Roteadores na borda da rede do ISP iro 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 servios especiais para clientes individuais. Por exemplo,
considere uma grande empresa com escritrios no Rio de Janeiro e em Porto Alegre. Supondo
que a empresa deseje uma conexo segura entre essas duas localidades com performances
garantidas, o ISP pode estabelecer um caminho na rede MPLS entre esses dois escritrios e
pode congurar os roteadores ao longo do caminho para garantir o desempenho contratado.
2.5.1 Classicao de pacotes

Como citado anteriormente, o MPLS por utilizar comutao por rtulos, 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 especique que todo trfego web percorra um determinado caminho diferente dos outros
trfegos.
Com isso, o modelo de camadas tradicional apresentado na seo Modelo em camadas
insuciente para a tarefa de seleo de caminhos na rede MPLS, j que no modelo tradicional
os datagramas em trnsito no so desencapsulados at a camada de transporte.
Logo, se faz necessrio denir a classicao de trfego. Um sistema de classicao difere
do desencapsulamento devido habilidade de atravessar as camadas.
Para entender a classicao de trfego, imagine um pacote que foi recebido no roteador
e colocado na memria. Pensando no pacote como um
array
de bytes, para saber se um
determinado pacote corresponde a um trfego web, basta vericar alguns bytes. Como por
exemplo, vericar os bytes correspondentes ao
Ethernet type,
para saber se um pacote
IP, vericar os bytes correspondentes ao campo protocolo, no pacote IP, para saber se o
protocolo utilizado o TCP e vericar os bytes correspondentes a porta de destino, para
vericar se os mesmos correspondem porta 80. Comer
(2013)
Observe que todas as aes representam pesquisas no
array
de bytes. O sistema de
classicao no precisa entender nenhum dos cabealhos dos protocolos ou o signicado

dos bytes.
Na prtica, o mecanismo de classicao geralmente utiliza uma srie de regras de classicao e as aplica at que uma correspondncia encontrada. Por exemplo, um gerente
pode especicar algumas regras como: enviar todo trfego web pelo caminho MPLS 1, enviar
todo trfego RTP pelo caminho MPLS 2 e enviar todo trfego VPN pelo caminho MPLS 3.
Captulo 3
SDN - Redes Denidas por Software
As redes de computadores atuais so compostas de inmeros 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 cenrio em mente, a ideia de redes programveis foi proposta com o objetivo
de facilitar futuras evolues nas redes de computadores. Nesse captulo, sero apresentados
os conceitos fundamentais das redes denidas 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 gerncia de
redes e permitir inovaes e evolues que o nosso modelo ossicado atual no permite
Nunes
et al.
(2014).
3.1 Engenharia de Trfego

O modelo bsico de encaminhamento de pacotes consiste em encaminhar o trfego com
um dado endereo IP de destino por um caminho pr-estabelecido pelos protocolos de roteamento. Independente das outras caractersticas dos pacotes, como endereo IP de origem,
portas TCP/UDP ou ToS, todo o trfego para um determinado endereo IP de destino, ao
chegar em um dado roteador, ser encaminhado pela mesma interface.
Isso exposto, surge a necessidade de realizar uma engenharia de trfego, ou seja, realizar
uma maior distino 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 distino e oferecem ao usurio nal garantias de qualidade
de servio, como por exemplo, as j citadas redes MPLS. Nas mesmas, atravs da criao
de circuitos virtuais e da comutao baseada em rtulos, pacotes com um mesmo endereo
IP de destino podem percorrer caminhos diferentes dentro de uma mesma rede.
Como ser visto, implementando o paradigma de redes denidas por software, haver um
salto na engenharia de trfego, j que cada uxo, ou seja, conjunto de pacotes de dados com
17
3.2
UM NOVO PARADIGMA EM REDES DE COMPUTADORES
18
algumas caractersticas em comum, poder ser tratado individualmente e novos softwares

e formas de encaminhar esses uxos podero 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 responsvel pela inteligncia do dispositivo. Por exemplo,
o plano de controle que executa os cdigos dos protocolos de roteamento, responsvel pela
realizao do clculo das rotas em roteadores. J o plano de dados responsvel por lidar
com os pacotes entrantes no dispositivo, vericando na tabela de encaminhamento por qual
interface o mesmo dever ser encaminhado.
Atualmente, os dispositivos convencionais apresentam uma estreita ligao entre esses
planos. Essa interligao torna rdua a depurao de conguraes e o controle do comportamento 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 denidas 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 programvel onde haver
um controlador de rede que coordenar todas as aes dos dispositivos. Esses dispositivos
encaminhadores de pacotes sero programados atravs de uma interface aberta, como, por
exemplo, a interface denida pelo OpenFlow, que ser visto no prximo captulo.
Atualmente, encontram-se no mercado switches OpenFlow (nomenclatura dada aos dispositivos burros) tanto puros quanto hbridos. Os puros, no apresentam nenhum plano de
3.2
19
controle, conando completamente no controlador para lhe dizer como encaminhar os pacotes. J os hbridos, suportam comandos do controlador em adio s operaes e protocolos
atuais Nunes
et al.
(2014).
A Figura 3.2 ilustra a comunicao do controlador externo com o dispositivo de rede.
Figura 3.2: Congurao bsica SDN, com um controlador externo congurando o dispositivo de
rede.
Fonte: Comer (2013)
Vale salientar que as redes denidas por software suportam tanto controladores externos
totalmente centralizados, ou seja, apenas um controlador com viso total da rede, quanto
distribudos, onde h alguns controladores controlando a rede (mesmo que de forma lgica
aparentem ser apenas um).
Na imagem 3.3, segue uma representao de dispositivos de redes genricos, com um
sistema operacional externo conhecedor de toda a topologia rodando no controlador e programas 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 benefcios e desaos/desvantagens com a sua implementao. Seguem abaixo alguns benefcios:
Visualizao unicada da rede - Com as redes denidas por software, passa-se a ter
uma viso global de toda a rede atravs do controlador, simplicando conguraes e
gerncia dos dispositivos.
Recuperao mais rpida 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
20
Figura 3.3: Representao de uma rede genrica.
Fonte: McKeown (2011)
uma nova tima congurao, devido a utilizao de algoritmos centralizados ao invs

de algoritmos distribudos.
Upgrade e implementao de novas aplicaes - Uma das maiores vantagens desse novo
paradigma a implementao de novas aplicaes para a rede. Novos protocolos e novas
formas de encaminhar os dados podero ser testadas e implementadas rapidamente,
pois no dependem mais de modicaes no rmware do switch ou do roteador. Alm
disso, o controlador pode ter seu software atualizado e alterado sem haver perda de
pacotes em uma rede em produo.
Alguns desaos/desvantagens encontrados so:
Segurana - Uma das maiores dvidas e preocupaes so a respeito da segurana.

Retirando a inteligncia dos dispositivos e levando-a para um controlador externo,
passaria-se a ter apenas um ponto crtico, onde caso seja violado, toda a rede sob esse
controlador estaria vulnervel. Essas preocupaes 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 prprios aparelhos

eletrnicos. Aliando esse conceito com uma rede programvel (onde inclusive vrus
podero ser programados com o objetivo de prejudicar o desempenho e comprometer
a rede), os gestores tero uma preocupao a mais, j que qualquer dispositivo pode
estar contaminado com um software malicioso ao se conectar na rede.
Conceito novo - As redes denidas por software assim como sua implementao mais
difundida, o OpenFlow, ainda se encontram imaturos. Muitos aspectos ainda precisam
ser amadurecidos e novas padronizaes realizadas. Como exemplo, qual o nvel de
3.2
21
dependncia os dispositivos genricos 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 distribuio e separao de
domnios de cada controlador?
Com a retirada do plano de controle dos dispositivos, pode-se modelar e moldar dinmicamente a rede, de acordo com a necessidade do gestor, permitindo que a gerncia da rede
seja feita de forma muito mais fcil e eciente.
Atualmente, as limitaes de largura de banda para cada tipo de servio so uma realidade, nos permitindo priorizar trfego VoIP por exemplo, sobre outras aplicaes. Entretanto, ao longo do dia, as necessidades dos usurios da rede podem ser alteradas e possivelmente uma determinada aplicao pode vir a ter uma prioridade maior que um trfego
VoIP.
Com redes denidas por software, em tempo real, pode-se haver essa troca de prioridades
e a determinada aplicao prioritria passa rapidamente a trafegar com alta prioridade.
Todo esse modelamento do trfego poder ser feito atravs de um console de gerncia, e
em instantes, os dispositivos da rede seriam congurados, no havendo mais a necessidade
de conectar-se a cada dispositivo.
Um exemplo similar pode ser visto no webinar da Cisco
onde, num primeiro momento, um
(Yamamoto e Scharra , 2014),
streaming de vdeo no era executado corretamente devido
a baixa prioridade e saturao do link principal. Aps rpidos ajustes no controlador, o link
secundrio (redundncia) que antes estava ocioso, passou a ser utilizado e o streaming foi
feito corretamente.
Outro exemplo de implementao foi apresentado pelo Google em 2012 na
Summit
Open Network
(conferncia destinada a discusses sobre SDN), onde o mesmo implementou uma
soluo OpenFlow/SDN no backbone que trafega os dados entre seus datacenters
Google
(2012).
Como visto, as redes denidas por software j so uma realidade, mesmo que ainda de
forma tmida. Muito precisa ser evoludo e amadurecido. Questes relativas segurana
precisam ser devidamente estudadas e analisadas. Mas a liberdade proporcionada por esse
modelo no deixa dvidas de que num futuro prximo as redes sero muito mais dinmicas
e programveis que as atuais, seja utilizando o paradigma SDN ou algum outro que venha
a ser derivado do mesmo.
Captulo 4
OpenFlow
Aps a denio do conceito das redes denidas por software, vista no captulo anterior,
algumas dvidas podem vir a surgir como:
Como se dar a comunicao entre o controlador e os dispositivos de rede genricos?
Quais conguraes 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 implementao mais difundida das redes denidas por software, o padro OpenFlow.
Criado originalmente na universidade de Stanford, o OpenFlow um padro aberto,
que surgiu da necessidade dos pesquisadores executarem protocolos experimentais na rede
acadmica.
uma tecnologia proposta para padronizar a forma como o controlador se comunica com
os dispositivos de rede em uma arquitetura SDN, denindo tambm um protocolo para essa
comunicao. Dessa forma, o OpenFlow prov meios de controlar os dispositivos de rede
(switches OpenFlow) sem a necessidade dos fabricantes exporem o cdigo de seus produtos.
Lara
et al.
(2014)
Assim, atravs 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 verses do protocolo OpenFlow esto disponveis. A primeira verso foi a 0.2.0
lanada em Maio de 2008 e atualmente est obsoleta. A verso 1.0.0 lanada em Dezembro
de 2009 foi a mais amplamente divulgada e implementada, com isso a mesma ter um
foco maior nesse trabalho. Aps a verso 1.0.0, foram lanadas as verses 1.1, 1.2, e 1.3 e
1.4
Lara
et al.
(2014).
O OpenFlow encontra-se em constante evoluo e o mesmo mantido pela ONF (
Network Foundation ).
22
Open
COMPOSIO DOS SWITCHES OPENFLOW
4.1
23
4.1 Composio dos switches OpenFlow

Baseando-se na verso 1.0.0, a verso mais difundida do OpenFlow, os switches OpenFlow
devem possuir/suportar as seguintes caractersticas McKeown
Tabela de Fluxos
Canal Seguro
Protocolo OpenFlow
et al.
(2008):
A tabela de uxos contm 12 campos que sero utilizados para a classicao de um

uxo, uma ao para cada uxo e contadores.
O canal seguro ir conectar o switch OpenFlow ao controlador e permitir que os comandos passem por ele.
J o protocolo OpenFlow o que ser utilizado para essa comunicao.
A Figura 4.1 ilustra as caractersticas citadas acima.
Figura 4.1: Switch OpenFlow idealizado.
Fonte: McKeown
et al.
(2008)
O switch OpenFlow deve ser capaz de realizar trs simples aes com os uxos entrantes:
Encaminhar o uxo entrante para uma determinada interface de sada, caso haja uma
entrada equivalente para o uxo em questo em sua tabela de uxos;
Caso no 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 atravs do canal seguro. O controlador que ir decidir o que fazer
TABELA DE FLUXOS
4.2
24
com esse pacote. Inclusive, decidir se uma entrada na tabela de uxos do switch ser
adicionada ou no;
Por ltimo, o switch OpenFlow tambm deve ser capaz de descartar pacotes;
4.2 Tabela de uxos

Como dito anteriomente, a tabela de uxos parte essencial da caracterizao 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 cabealho so os campos que sero comparados com o uxo entrante no

switch OpenFlow. A Figura 4.3, apresenta os campos denidos na verso 1.0.0:
Figura 4.3: Campos de cabealho.
Fonte: Foundation
(2009)
Cada campo do cabealho pode ser ou no denido. Por exemplo, para o switch OpenFlow
funcionar como um roteador, basta especicar 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 sero incrementados sempre que uxos correspondentes
s entradas na tabela entrem no switch e sero utilizados em mensagens de estatsticas,
tambm denidas pelo OpenFlow.
A Figura 4.4 apresenta os contadores disponveis:
TABELA DE FLUXOS
4.2
25
Figura 4.4: Lista dos contadores.
Fonte: Foundation
(2009)
Quanto s aes que devero ser tomadas com os pacotes, existem aes obrigatrias
que todos os switches OpenFlow devem implementar e outras opcionais. Ao se conectar
ao controlador, o switch deve informar quais aes opcionais o mesmo implementa. Cada
entrada na tabela de uxos associada a uma ou mais aes. Se para uma determinada
entrada na tabela no houver uma ao especicada, os pacotes desse uxo sero descartados.
Abaixo seguem os tipos de aes:
Encaminhamento
Obrigatrio
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 aes 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

considerao o Spanning Tree.
TABELA DE FLUXOS
4.3
26
Enleirar (opcional) - Encaminha o pacote atravs de uma la relacionada a uma

porta;
Descartar (obrigatria)
Modicar campo (opcional)
Setar Vlan ID
Setar Vlan Priority
Separar o cabealho da Vlan
Modicar endereo MAC (
Modicar endereo MAC de destino
Modicar endereo IP de origem
Modicar endereo IP de destino
Modicar ToS
Modicar a porta de transporte de origem
Modicar a porta de transporte de destino
Media Access Control ) de origem
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 especcas tm
prioridade, entradas na tabela de uxos que especiquem exatamente o uxo entrante, ou
seja, entradas na tabela que no apresentem campos coringa, tero sempre a mais alta
prioridade.
O CANAL SEGURO
4.3
27
4.3 O canal seguro

Outra parte essencial da caracterizao de um switch OpenFlow o estabelecimento
de um canal seguro com o controlador. Atravs desse canal, o controlador ir congurar e
gerenciar o switch OpenFlow. De acordo com Comer (2013), embora uma conexo TCP seja
permitida entre o switch e o controlador, o uso de SSL/TLS recomendado com o objetivo
de garantir condencialidade em toda comunicao. importante lembrar que o OpenFlow
no requer uma conexo fsica direta entre o switch e o controlador, podendo utilizar redes
j em produo para efetuar a comunicao. Por isso, a importncia de um canal seguro.
O protocolo OpenFlow suporta trs tipos diferentes de mensagens:
Controlador-Switch - Geradas pelo controlador para gerenciar e inspecionar o estado

de um switch;
Assncronas - Geradas pelo switch para atualizar o controlador sobre eventos da rede
e mudanas no estado do switch;
Simtricas - Podem ser geradas tanto pelo controlador quanto pelo switch. So enviadas
sem solicitao;
Abaixo, os sub-tipos de cada uma:
Controlador-Switch
Caractersticas (
Features ) - O controlador requisita as caractersticas do switch.
O switch deve responder com as caractersticas suportadas;
Conguration )
Congurao (
- Usado para congurar ou solicitar conguraes
do switch;
Modify-State ) - Usado para adicionar, deletar e modicar
Modicao de estado (
a tabela de uxos e para setar propriedades nas portas do switch;
Leitura de estado (
Envio de pacote (
Read-State ) - Coleta estatsticas;
Send-Packet ) - Utilizado para enviar pacotes por uma determi-
nada porta do switch;
Barreira (
Barrier )
- Usado para garantir que as dependncias foram atendidas
ou para receber noticaes de operaes nalizadas;
Assncrona
Entrada de pacotes (
Packet-In ) - Utilizado quando uxos no classicados entram
no switch.
Flow-Removed ) - Mensagem enviada para o controlador, quando
Remoo de uxo (
um uxo removido da tabela. Seja por Idle Timeout, Hard Timeout ou por uma
mensagem de modicao da tabela de uxos que delete a entrada em questo;
O CANAL SEGURO
4.3
Port-Status )
Estado da porta (
28
- Mensagem enviada para o controlador sempre
que h mudanas nas conguraes das portas;
Erro (
Error ) - Noticaes de erros;
Simtrica
Hello
- Mensagens trocadas entre o controlador e o switch quando uma conexo
estabelecida;
Echo
- Mensagens usadas para identicao de latncia, largura de banda e exis-
tncia de conectividade;
Vendor
- Provem uma forma padro para os switches OpenFlow oferecerem
funcionalidades adicionais;
No estabelecimento de uma comunicao OpenFlow, cada um dos lados (controlador e
switch) devem enviar imediatamente uma mensagem
Hello
(OFPT_HELLO), contendo a
mais alta verso do protocolo OpenFlow suportada pelo dispositivo. Ao receber a mensagem,
o dispositivo deve escolher a menor verso do OpenFlow entre a que foi enviada e recebida.
Se as verses forem compatveis, a comunicao tem continuidade. Caso no sejam, uma
mensagem de erro gerada (OFPT_ERROR) e a conexo encerrada.
interessante informar tambm que, caso haja alguma perda de conexo entre o switch
e o controlador, o switch tentar se conectar ao controlador back-up, caso exista. Caso essa
conexo tambm falhe, o switch entrar em modo de emergncia, modo esse que utilizar
apenas as entradas na tabela de uxos marcadas com um bit de emergncia e todas as outras
entradas sero deletadas.
Para modicar 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 modicao da tabela de uxos.
Fonte: Foundation
Como pode ser observado, as mensagens

as mensagens do tipo
MODIFY
ADD
(2009)
adicionaro entradas na tabela de uxos,
modicaro entradas j existentes e as mensagens do tipo
DELETE apagaro entradas na tabela de uxo. As mensagens *_STRICT (OFPFC_MODIFY_STRICT

e OFPFC_DELETE_STRICT) buscaro entradas na tabela de uxos idnticas s especicadas.
Alm das mensagens OFPFC_DELETE e OFPFC_DELETE_STRICT as entradas na
tabela de uxos podem ser removidos por
idle_timeout
ou
hard_timeout. Caso no entrem
OUTRAS VERSES
4.4
pacotes correspondentes a uma determinada entrada na tabela em

ou caso transcorra
hard_timeout
idle_timeout
29
segundos
segundos aps a insero da entrada na tabela, a entrada
ser apagada.
4.4 Outras verses

Nas sees acima, o OpenFlow 1.0.0 foi apresentado em maiores detalhes, considerando
que o mesmo a verso mais utilizada e difundida. Entretanto, muitas mudanas foram
realizadas desde o lanamento da verso 1.0.0 at a verso mais atual, a 1.4. Abaixo, seguem
algumas caractersticas das verses subsequentes:
4.4.1 OpenFlow 1.1

Na especicao do OpenFlow 1.1, os switches OpenFlow contm diversas tabelas de
uxos e uma tabela de grupo, ao invs de uma nica tabela de uxos como na verso 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)
OUTRAS VERSES
4.4
30
Figura 4.8: Fluxograma detalhando o uxo de pacotes atravs do switch OpenFlow 1.1
Fonte: Foundation
(2011a)
Logo, um uxo de pacotes ao entrar no switch OpenFlow, poder passar por vrias
tabelas de uxos, para que diversas aes diferentes sejam realizadas.
A tabela de grupo um tipo especial de tabela projetada para executar aes que sejam
comuns para diversos uxos.
Metadata
MPLS label e MPLS
Alm disso, na verso 1.1.0 , trs novos campos de cabealho foram includos:
(pode ser usada para passar informaes entre as tabelas no switch),
trac class.
Maiores detalhes podem ser encontrados na especicao OpenFlow 1.1.0 em Foundation

(2011a).
4.4.2 OpenFlow 1.2

O OpenFlow 1.2 foi lanado em dezembro de 2011 e uma das principais implementaes
foi o suporte ao protocolo IPv6, incluindo novos campos de cabealho nas tabelas de uxos.
Alm disso, o mesmo passou a suportar a possibilidade dos switches se conectarem a mais
de um controlador ao mesmo tempo. Ao se conectar a vrios controladores, aumenta-se a
segurana j que o switch pode continuar a operar normalmente mesmo se um controlador
ou a conexo car indisponvel
Lara
et al.
(2014).
Maiores detalhes em Foundation (2011b).
OUTRAS VERSES
4.4
31
4.4.3 OpenFlow 1.3

Sendo lanada em Junho de 2012, a verso 1.3.0 do OpenFlow passou a suportar o
controle das taxas de pacotes atravs de medidores de uxos, introduzindo a tabela de
Meter Table ). A tabela de medies por uxo permite ao OpenFlow implementar
medies (
simples operaes de QoS, como limitao de taxas de transmisso e pode ser combinada
com as las por porta para criar polticas de QoS mais complexas. Alm disso, a verso
1.3 permite ao switch criar conexes 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 verso 1.4 do OpenFlow portas pticas passaram a ser suportadas. Alm disso, os
conceitos de
Eviction
Vacancy events
foram introduzidos para evitar que as tabelas de
uxos quem cheias, j que as mesmas tem capacidades nitas. Nas especicaes anteriores
quando uma tabela de uxos enchia, novos uxos no eram inseridos nas tabelas e uma
mensagem de erro era enviada para o controlador. Entretanto, atingir tal situao era problemtico e poderia causar interrupes no servio. O
Eviction
adiciona um mecanismo que
permite ao switch apagar automaticamente as entradas nas tabelas de uxos que tenham
menor importncia. J o
Vacancy events
permite ao controlador congurar um limiar, que
ao ser atingido, faz o switch enviar mensagens de alerta para o controlador. Isso permite
que o controlador possa reagir com antecedncia, evitando que as tabelas de uxos quem
cheias Foundation (2012b).
As subsees acima deram apenas uma viso global sobre as caractersticas das verses do OpenFlow posteriores 1.0.0. Maiores detalhes e outras caractersticas podem ser
encontradas nas especicaes tcnicas, citadas na bibliograa.
POX
4.5
32
4.5 POX
Como visto anteriormente, o controlador parte fundamental nas redes denidas por software, j que sero os mesmos que iro denir a lgica de encaminhamento atravs das regras
que iro congurar nos switches OpenFlow. Atualmente, existem alguns disponveis para o
uso, como o NOX (Gude
Maestro (Cai
et al. ,
et al. ,
2008), POX (http://www.noxrepo.org/pox/about pox/ ),
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 clssico,
um dos primeiros controladores OpenFlow. O POX apresenta como vantagens o fato de ser
implementado em Python, sendo ideal para o ambiente acadmico. Alm disso, o mesmo
apresenta diversos componentes reusveis e bibliotecas interessantes como as seguintes:
Link Layer Discovery Protocol )
openow.discovery: Utiliza mensagens LLDP (
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
ou
down. Esse componente foi essencial para a aplicao desenvolvida;
up
openow.spanning_tree: Esse componente utiliza o discovery para contruir uma viso da topologia da rede e constri uma
spanning tree
para desabilitar a inundao
ooding ) nas portas dos switches que no esto na rvore;
pox.lib.revent: Biblioteca do POX que implementa eventos. Todos eventos do POX so

instncias de sub-classes da classe
Event ;
threads e timers ;
pox.lib.recoco: Biblioteca do POX que implementa
pox.lib.addresses: Biblioteca utilizada para lidar com endereos IP e Ethernet (MAC);
Captulo 5
Mininet
O ambiente utilizado para o desenvolvimento da aplicao e realizao dos testes foi o
Mininet. Este se trata de um emulador de redes, desenvolvido por pesquisadores da Universidade de Stanford nos Estados Unidos, com o objetivo de apoiar pesquisas colaborativas
permitindo prottipos autnomos de redes denidas por software, para que qualquer pessoa
et al. (2010).
O Mininet um emulador do tipo CBE (Container-Based Emulation ) que emprega a vir-
possa fazer o download, executar, avaliar, explorar e ajustar Lantz
tualizao a nvel de processo, uma forma mais leve de virtualizao onde muitos recursos do
sistema so compartilhados. Compartilhando recursos como tabela de paginao, estruturas
de dados do
kernel
e sistema de arquivos, esse tipo de emulao alcana maior escalabilidade
que outras que realizam uma emulao completa, ou seja, usando uma mquina 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 diferenas citadas acima, entre CBE e a virtualizao
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: Virtualizao completa dos dispositivos.
Figura 5.3: Virtualizao "leve"dos dispositivos.
O Mininet capaz de emular links, hosts, switches e controladores, utilizando processos
network namespaces ) e pares Ethernet virtuais.
que rodem em espaos de nomes da rede (
Links: Um par Ethernet virtual atua como um cabo conectando duas interfaces virtuais.
Pacotes enviados atravs de uma interface so entregues na outra e cada interface se
comporta como uma interface Ethernet completa e funcional para todo o sistema e
aplicao.
Host: simplesmente um processo do shell movido para o seu prprio espao de nome
da rede, ou seja, cada host apresenta uma instncia 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 sada.
Switches: Switches OpenFlow so remotamente congurados e gerenciados pelo con-
5.0
35
trolador, podendo ser congurados para agirem como switches convencionais.
Controladores: Controladores OpenFlow podem estar em qualquer lugar da rede, ou

seja, tanto na rede fsica 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, atravs de um nico console,
pode-se controlar todos os dispositivos emulados. Outra grande vantagem desse emulador
a facilidade de criao de topologias customizadas atravs de uma API (
gramming Interface ) para programao em Python.
Application Pro-
O projeto Mininet nasceu com o objetivo de facilitar os experimentos no campo de

redes de computadores, principalmente para auxiliar nas pesquisas das redes denidas por
software e do OpenFlow. Pode ser vericado em Heller
(2013) uma anlise completa do
Mininet, incluindo uma comparao 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 vericada a robustez do Mininet ao reproduzir
diversos experimentos de redes de computadores escolhidos por estudantes.

O emulador Mininet encontra-se em constante evoluo, sendo mantido por uma ativa
comunidade online. O mesmo encontra-se na verso 2.1.0 lanada em Setembro de 2013.
Captulo 6
A aplicao desenvolvida
Com a tecnologia de redes de computadores atual, torna-se invivel o teste de novos
protocolos em redes que estejam em produo, j que as mesmas foram implementadas com
hardwares especcos, que no permitem uma reprogramao.
Conforme visto nos captulos anteriores, com as redes denidas por software, essa limitao j no mais existir. Equipamentos especcos se tornam genricos e a gura do
controlador aparece para que possa existir uma rede programvel e para que mudanas na
forma de encaminhar os pacotes possam ser realizadas rapidamente.
A aplicao desenvolvida busca mostrar essa facilidade presente nas redes denidas 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 utilizados conceitos do algoritmo de Dijkstra para o clculo dos caminhos e mdulos presentes
no POX, como ser visto adiante.
6.1 Executando a aplicao

Ao se inicilizar a aplicao, a primeira ao que realizada a descoberta da rede. O
mdulo discovery presente no POX faz a descoberta da conectividade entre swicthes OpenFlow enviando pacotes LLDP. A Imagem 6.1, gerada atravs de uma captura no Wireshark,
mostra os pacotes LLDP:
Figura 6.1: Pacotes LLDP.
36
EXECUTANDO A APLICAO
6.1
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 parmetro que signique
que quanto maior o valor, pior o enlace. Para a emulao realizada, se utilizou um gerador
de nmeros aleatrios para a denio dos pesos de cada enlace. Aps a topologia ser salva,
com a descoberta de todos os switches e a atribuio dos pesos, o algoritmo de Dijkstra ,
ento, executado em um codigo complementar.
Esse cdigo complementar (Anexo 10.1), utiliza conceitos do algoritmo de Dijkstra para
realizar o clculo da melhor e da segunda melhor rotas entre os switches OpenFlow. O cdigo
recebe como parmetros 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 ns.
A Figura 6.2 apresenta um uxograma representando essa primeira etapa:
Figura 6.2: Fluxograma representando primeira etapa da execuo da aplicao.
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 cdigo 10.1 ser executado.

Ao receber um pacote, o switch enviar uma mensagem de
Packet-In para o controlador,
se o switch no possuir entradas em sua tabela de uxos. A aplicao no controlador tratar
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
de maneiras diferentes pacotes ARP (
seja, o controlador informa ao switch apenas qual deve ser a ao a ser tomada para um
pacote, no havendo modicao 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
Caso o pacote no seja ARP, o controlador gera uma mensagem de
Flow-Mod
38
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 aplicao monitora a taxa de transmisso,
fazendo requisies peridicas de estatsticas do uso da interface. A quantidade de bytes
transmitidos pela porta conectada ao prximo switch (prximo switch de acordo com o
melhor caminho calculado) salva em uma varivel e ser comparada com a quantidade da
coleta anterior.
Como na topologia denida para o teste (Anexo 9.1) os links foram denidos com uma
largura de banda de 100 Mbps, feito um clculo com a diferena de bytes transmitidos
em duas coletas e verica-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 so chaveados para a segunda melhor rota.
6.1
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 mudanas de rotas a todo momento, foi implementada uma histerese. Assim,
existe um contador que salva o nmero de ocorrncias 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 mnimo o tempo que cou acima desse limiar. Vale ressaltar que o valor mximo desse
contador 5 (25 segundos).
O incremento desse contador, assim como outros detalhes menores, no foi indicado no
uxograma
A aplicao mostra como o controlador pode agir proativamente com o objetivo de evitar
sobrecarga do link e descartes ou at mesmo para a implementao de polticas de QoS de
forma facilitada. Vale ressaltar, que a escolha da porta UDP 2000 foi feita de forma aleatria
e, com facilidade, o cdigo pode ser generalizado para quaisquer portas ou at mesmo para
que altere a rota levando em considerao quaisquer outros campos de cabealho denidos
em 4.2.
O cdigo completo desenvolvido pode ser analisado no Anexo 11.1.
1 Em
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 melhor
caminho. Entretanto mesmo aps estressar o link, o contador dos pacotes descartados no foi incrementado.
Acreditando ser uma limitao do Mininet, optou-se ento pela anlise da utilizao da largura de banda
Captulo 7
Simulao e resultados
Para a realizao dos testes, foi utilizada uma topologia redundante
Como a proposta dessa monograa apresentar as redes denidas por software, mostrando a facilidade com que aplicaes podem ser desenvolvidas, uma topologia simples foi
escolhida para a realizao dos testes.
Nela, foram congurados trs hosts e cinco switches. Todos os enlaces foram denidos
com as mesmas caractersticas, com o objetivo de facilitar os testes e a anlise dos resultados.
As principais caractersticas so:
bw - Largura de banda de 100Mbps;
loss - Perda do link de 1%;
delay - Atraso de 5ms;
max_queue_size - Tamanho mximo da la de 10000 pacotes;
A Figura 7.1, ilustra a topologia utilizada.

Primeiramente, o Mininet inicializado com a topologia personalizada criada e com alguns parmetros extras, para que os endereos MAC quem de forma mais legvel e denindo
que o controlador ser externo, como pode ser visto na Figura 7.2.
Aps a inicializao do emulador Mininet, a aplicao inicializada. Como pode ser
visto na Figura 7.3 a aplicao iniciada com os mdulos j citados do POX, discovery e
spanning_tree (4.5), j que por padro o spanning_tree no ativado.
Para gerar o trfego para os testes, foi utilizado o Iperf (iperf.fr ). Com o Iperf, possvel
congurar um host para atuar como servidor, escutando em uma determinada porta e
hosts como clientes, que iro enviar trfegos para o servidor.
1 Descrio
da topologia para o Mininet denida no Anexo 9.1
40
METODOLOGIA
7.1
41
Figura 7.1: Topologia utilizada nos testes.
Figura 7.2: Inicializao do Mininet.
Figura 7.3: Inicializao da aplicao.
7.1 Metodologia
Na topologia congurada, o host 3 foi denido como o servidor, e os hosts 1 e 2 como
clientes. Logo, os hosts 1 e 2 geraro trfegos para o host 3. Deniu-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. Alm disso, ambas comunicaes tentaro
utilizar 100% da largura de banda e ambos os uxos so 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
intrnsecos de cada caminho, para que se tenha uma base de comparao para os prximos
procedimentos.
Cada um dos procedimentos foi repetido seis vezes, sendo cada um deles executados aps
a inicializao do Mininet e do controlador.
METODOLOGIA
7.1
Figura 7.4: Comandos do Iperf nos clientes.
Figura 7.5: Comandos do Iperf no servidor.
A Figura 7.6, apresenta o grco 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, aps o primeiro teste.
42
METODOLOGIA
7.1
43
Figura 7.6: Percentual da perda de pacotes com os uxos sendo enviados sempre por caminhos
diferentes.
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 vericar qual a porcentagem dos pacotes perdidos, sem utilizar o
chaveamento para o segundo melhor caminho.
O grco com o percentual de perda dos pacotes, nos seis testes realizados, apresentado
na Figura 7.8.
Na Figura 7.9 segue resposta do servidor aps o primeiro teste.
METODOLOGIA
7.1
44
Figura 7.8: Percentual da perda de pacotes com ambos os uxos sendo enviados sempre pelo melhor
caminho.
Figura 7.9: Teste com dois hosts enviando pelo mesmo caminho.
Por m, realiza-se o teste com o chaveamento dinmico ativado. A congurao do caminho alternativo efetuada caso a utilizao 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 aps o primeiro teste.
Na Figura 7.12, segue a tabela de uxos do switch 1, mostrando a modicao da interface
de sada para os uxos que tenham porta UDP igual a 2000.
METODOLOGIA
7.1
45
Figura 7.10: Percentual da perda dos pacotes, realizando a mudana de rota dinamicamente.
Figura 7.11: Resultado do primeiro teste.
Os grcos dos percentuais mdios de cada procedimento so apresentados na Figura

7.13. J o grco com as taxas mdias de transmisso dos uxos apresentado na Figura
7.14.
Figura 7.12: Tabela de uxos do switch 1.
METODOLOGIA
7.1
46
Figura 7.13: Percentual mdio dos erros
Figura 7.14: Taxa de transmisso mdia
Como pode ser vericado, o uso da aplicao reduziu consideravelmente as perdas de

pacotes de todos os uxos, chegando a valores prximos ao experimento dos uxos sempre
por caminhos diferentes. Para os testes em questo, que foram realizados por um perodo de
180 segundos, a reduo de 1% na perda dos pacotes, equivale a um ganho na recepo de
aproximadamente 8000 pacotes!
Considerando que a reduo da perda foi de aproximadamente 5%, ca bastante clara a
7.1
melhoria na entrega dos pacotes.
METODOLOGIA
47
Captulo 8
Concluses
Esse trabalho teve como objetivo introduzir um paradigma diferente da atual implementao de redes de computadores. Modelo esse que pode vir a ser o predominante em poucos
anos.
Buscando ajudar na compreensso das redes denidas por software, no Captulo 2, conceitos bsicos de redes de computadores foram explanados. Conceitos como modelo em camadas, encaminhamento, roteamento e classicao de pacotes, serviram como uma base
para os conceitos seguintes.
O Captulo 3 dene as redes denidas por software, modelo que prope a separao dos
planos de controle e dados, planos esses encontrados nos dispositivos de redes como switches
e roteadores. Com sua separao, possivel ter um controle total da rede. J no so mais
necessrios hardwares especcos, mas hardwares genricos podem ser utilizados e, atravs
do controlador, podem ser programados.
O Captulo 4 apresenta o OpenFlow, implementao mais difundida das redes denidas
por software. Um enfoque maior dado a verso 1.0.0, a verso mais utilizada do OpenFlow.
Entretanto, as diferenas entre as verses mais novas como as verses 1.1, 1.2, 1.3 e 1.4 so
citadas. Nesse captulo, apresentado tambm o POX, controlador implementado em Python
e que foi utilizado nesse trabalho.
No Captulo 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 virtualizao, onde muitos recursos do sistema so compartilhados.
Nos Captulos seguintes, a aplicao nalmente descrita e seus resultados mostrados.
Como foi visto, uma topologia simples com cinco switches e trs hosts foi utilizada. Fluxos
so gerados por dois hosts clientes para o servidor e de acordo com a utilizao da largura
de banda, o caminho de um desses uxos pode ser alterado.
Como visto, foram realizados trs procedimentos. No primeiro, foram realizadas uma srie
de testes com o objetivo de descobrir a perda intrnseca dos caminhos. Ao fazer isso, encontrase uma base, com a qual podero ser comparados os resultados dos prximos procedimentos.
No segundo procedimento, testes so realizados com os dois uxos sendo enviados pelo
48
8.0
49
mesmo caminho. O objetivo vericar a quantidade de pacotes que esto sendo perdidos
devido utilizao do mesmo link.
No terceiro procedimento, os testes realizados utilizam a aplicao para realizar o chaveamento de um uxo especco (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 utilizao do link principal seja maior ou igual a 70Mbps.
No nal do captulo, um grco comparativo dos trs procedimentos apresentado. Nele,
percebe-se que a utilizao 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 esperado e da proposta inicial. Ainda, o cdigo da aplicao futuramente pode ser modicado,
buscando deix-lo mais genrico ou adequando-o a uma outra situao especca.
Captulo 9
Apndice A
9.1 Cdigo para criao da topologia
#T o p o l o g i a 5 s w i t c h e s 3 h o s t s
from mininet . topo import Topo

c l a s s 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
s2
s3
s4
s5
=
=
=
=
=
self
self
self
self
self
. addSwitch (
. addSwitch (
. addSwitch (
. addSwitch (
. addSwitch (
' s1 '
' s2 '
' s3 '
' s4 '
' s5 '
)
)
)
)
)
#Adicionando l i n k s
s e l f . addLink ( h1 , s1 , bw=100 , d e l a y= ' 5ms ' , l o s s =1,max_queue_size =10000 ,

use_htb=True )
use_htb=True )
use_htb=True )
50
CDIGO PARA CRIAO DA TOPOLOGIA
9.1
s e l f . addLink ( s1 , s2 , bw=100 , d e l a y= ' 5ms ' , l o s s =1,max_queue_size =10000 ,

use_htb=True )
use_htb=True )
use_htb=True )
use_htb=True )
use_htb=True )
use_htb=True )
topos = { ' mytopo ' : ( lambda : MyTopo ( ) ) }

Cdigo 9.1: Cdigo topologia.py em Python para a criao da topologia, denindo a quantidade
de hosts, swicthes e caractersticas dos enlaces
51
Captulo 10
Apndice B
10.1 Cdigo para calcular as rotas
# Executa a l g o r i t m o de D i j a k s t r a , c a l c u l a n d o o melhor e o segundo melhor
caminho ;
def recebe_dados ( no_origem , t o p o l o g i a ) :

d i s t a n c i a s = {}
d i s t a n c i a s _ s e g u n d o = {}
v i z i n h o s = {}
vizinhos_segundo = {}
num_nos , nos = calcula_num_nos ( t o p o l o g i a )
nos_segundo = nos [ : ]
for no in nos :
v i z i n h o s [ no ] = [ ]
for i in t o p o l o g i a :
i f ( no == i [ 0 ] ) :
v i z i n h o s [ no ] . append ( [ i [ 2 ] , i [ 1 ] ] )
i f ( no == i [ 2 ] ) :
v i z i n h o 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 :

vizinhos_segundo [ no_segundo ] = [ ]
for i in t o p o l o g i a :
i f ( no_segundo == i [ 0 ] ) :
vizinhos_segundo [ no_segundo ] . append ( [ i [ 2 ] , i [ 1 ] ] )
52
CDIGO PARA CALCULAR AS ROTAS
10.1
i f ( no_segundo == i [ 2 ] ) :
vizinhos_segundo [ no_segundo ] . append ( [ i [ 0 ] , i [ 1 ] ] )
i f ( no_segundo != no_origem ) :
d i s t a n c i a s _ s e g u n d o [ no_segundo ] =[ 1, 1, 0 ]
for j in v i z i n h o s [ no_origem ] :
distancias [ j [ 0 ] ] = j
d i s t a n c i a s [ j [ 0 ] ] . append ( 0 )
for l in vizinhos_segundo [ no_origem ] :

distancias_segundo [ l [ 0 ] ] = l
d i s t a n c i a s _ s e g u n d o [ l [ 0 ] ] . append ( 0 )
visitado = 0
while v i s i t a d o == 0 :
peso_minimo = 1
no_custo_minimo = None
visitado = 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
visitado = 0
i f v i s i t a d o == 0 :
for v i z i n h o in v i z i n h o s [ no_custo_minimo ] :
i f v i z i n h o [ 0 ] != no_origem :
i f ( d i s t a n c i a s [ no_custo_minimo ] [ 1 ] + v i z i n h o [ 1 ] <= d i s t a n c i a s [
v i z i n h o [ 0 ] ] [ 1 ] ) or ( d i s t a n c i a s [ v i z i n h o [ 0 ] ] [ 1 ] == 1) :
d i s t a n c i a s [ v i z i n h o [ 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 i n h o [ 0 ] ] [ 1 ] = d i s t a n c i a s [ no_custo_minimo ] [ 1 ] +
vizinho [ 1 ]
d i s t a n c i a s [ no_custo_minimo ] [ 2 ] = 1
vi si tad o_ se gun do = 0
while vi si tad o_ se gun do == 0 :
53
10.1
peso_minimo_segundo = 1
no_custo_minimo_segundo = None
vi si ta do_ se gun do = 1
for j in d i s t a n c i a s _ s e g u n d o :
i f ( d i s t a n c i a s _ s e g u n d o [ j ] [ 2 ] == 0) :
i f ( d i s t a n c i a s _ s e g u n d o [ j ] [ 1 ] != 1) :
i f ( ( peso_minimo_segundo == 1) or ( peso_minimo_segundo >
distancias_segundo [ j ] [ 1 ] ) ) :
peso_minimo_segundo = d i s t a n c i a s _ s e g u n d o [ j ] [ 1 ]
no_custo_minimo_segundo = j
vi si tad o_ se gun do = 0
i f vi si tad o_ se gun do == 0 :
for v i z i n h o in vizinhos_segundo [ no_custo_minimo_segundo ] :
i f v i z i n h o [ 0 ] != no_origem :
soma_distancias = d i s t a n c i a s _ s e g u n d o [ no_custo_minimo_segundo ] [ 1 ]
+ vizinho [ 1 ]
i f ( ( soma_distancias < d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 1 ] ) or (
d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 1 ] == 1) ) :
i f ( ( soma_distancias > d i s t a n c i a s [ v i z i n h o [ 0 ] ] [ 1 ] or
d i s t a n c i a s _ s e g u n d o [ no_custo_minimo_segundo ] [ 0 ] !=
d i s t a n c i a s [ no_custo_minimo_segundo ] [ 0 ] ) ) :
distancias_segundo [ vizinho [ 0 ] ] [ 0 ] = distancias_segundo [
no_custo_minimo_segundo ] [ 0 ]
d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 1 ] = soma_distancias
i f ( ( d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 0 ] == d i s t a n c i a s [ v i z i n h o
[ 0 ] ] [ 0 ] ) and ( d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 1 ] == d i s t a n c i a s
[ vizinho [ 0 ] ] [ 1 ] ) ) :
i f ( d i s t a n c i a s [ no_custo_minimo_segundo ] [ 0 ] !=
distancias_segundo [ vizinho [ 0 ] ] [ 0 ] ) :
d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 0 ] = no_custo_minimo_segundo
distancias_segundo [ vizinho [ 0 ] ] [ 1 ] = d i s t a n c i a s [
no_custo_minimo_segundo ] [ 1 ] + v i z i n h o [ 1 ]
else :
d i s t a n c i a s _ s e g u n d o [ v i z i n h o [ 0 ] ] [ 0 ] = no_custo_minimo_segundo
distancias_segundo [ vizinho [ 0 ] ] [ 1 ] = distancias_segundo [
no_custo_minimo_segundo ] [ 1 ] + v i z i n h o [ 1 ]
d i s t a n c i a s _ s e g u n d o [ no_custo_minimo_segundo ] [ 2 ] = 1
54
10.1
#For n e c e s s a r i o d e v i d o ao problema quando um no so t i n h a um u n i c o

v i z i n h o 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 n e c e s s a r i o p o i s como o D j a k s t r a e chamado a n t e s de t o d a a t o p o l o g i a
e s t a r c r i a d a , e l e dava e x c e p t i o n . Caso o c o d i g o s e j a chamado apenas
apos a c r i a c a o de t o d a a t o p o l o g i a , a e x c e c a o nao a p a r e c e r a mais .
try :
for chaves in vizinhos_segundo . keys ( ) :
i f vizinhos_segundo [ chaves ] [ 0 ] != no_origem :
i f len ( vizinhos_segundo [ chaves ] ) == 1 and d i s t a n c i a s _ s e g u n d o [
chaves ] [ 0 ] == 1:
d i s t a n c i a s _ s e g u n d o [ chaves ] [ 1 ] = d i s t a n c i a s _ s e g u n d o [
vizinhos_segundo [ chaves ] [ 0 ] [ 0 ] ] [ 1 ] + vizinhos_segundo [ chaves
][0][1]
d i s t a n c i a s _ s e g u n d o [ chaves ] [ 0 ] = d i s t a n c i a s _ s e g u n d o [
vizinhos_segundo [ chaves ] [ 0 ] [ 0 ] ] [ 0 ]
d i s t a n c i a s _ s e g u n d o [ chaves ] [ 2 ] = 1
except Exception :
pass
return d i s t a n c i a s , d i s t a n c i a s _ s e g u n d o
#C a l c u l a q u a n t o s nos ha na t o p o 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
Cdigo 10.1: Cdigo dijkstra.py em Python utilizado para calcular a melhor e a segunda melhor
rotas
55
Captulo 11
Apndice C
11.1 Cdigo da aplicao
from pox . c o r e import c o r e
from pox . l i b . r e v e n t import
import pox . openflow . libopenflow_01 as o f
import pox . openflow . d i s c o v e r y
import pox . openflow . spanning_tree
from random import randrange
import djakstra_v2
from time import s l e e p
from pox . l i b . a d d r e s s e s import IPAddr
from pox . l i b . r e c o c o import Timer
from pox . openflow . of_json import
l o g=c o r e . getLogger ( )
c l a s s switch_multi ( object ) :
mac_map={}
d e l a y _ l i n k s ={}
def __init__ ( s e l f ) :
def s t a r t u p ( ) :
c o r e . openflow . a d d L i s t e n e r s ( s e l f , p r i o r i t y =0)
c o r e . openflow_discovery . a d d L i s t e n e r s ( s e l f )
#L i s t e n e r para e v e n t o s e s t a t i s t i c o s
c o r e . openflow . addListenerByName ( " FlowStatsReceived " , s e l f .

handle_flow_stats )
56
CDIGO DA APLICAO
11.1
c o r e . openflow . addListenerByName ( " P o r t S t a t s R e c e i v e d " , s e l f .

handle_portstats_received )
s e l f . c o n n e c t i o n s = set ( )
c o r e . call_when_ready ( s t a r t u p , ( ' openflow ' , ' openflow_discovery ' ) )
#D i c i o n a r i o chave IP ; v a l o r e s MAC origem e p o r t a do s w i t c h
self
self
self
self
self
self
self
self
. mac_map = {}
. topologia = [ ]
. d e l a y _ l i n k s = {}
. p o r t a s = {}
. dij_1_melhor = [ ]
. dij_2_melhor = [ ]
. dij_1_segundo = [ ]
. dij_2_segundo = [ ]
#Contador que s e r a u t i l i z a d o para e x e c u t a r o D j a k s t r a . Sem o mesmo , o

a l g o r i t i m o de D j a k s t r a e e x e c u t a d o , sem os l i n k s terem s i d o
descobertos .
s e l f . count = 0
s e l f . link_count = 0
s e l f . tx_1 = 0
s e l f . tx_2 = 0
s e l f . diferenca = 0
s e l f .LINK_OK = True
s e l f .JA_ENTROU = F a l s e
def _handle_LinkEvent ( s e l f , event ) :

chave_1
chave_2
delay_1
delay_2
=
=
=
=
str ( event . l i n k . dpid1 )+str ( event . l i n k . dpid2 )

str ( event . l i n k . dpid2 )+str ( event . l i n k . dpid1 )
s e l f . d e l a y _ l i n k s . g e t ( chave_1 )
s e l f . d e l a y _ l i n k s . g e t ( chave_2 )
i f ( delay_1 == None and delay_2 == None ) :

d e l a y = None
chave = chave_1
e l i f delay_1 != None :
d e l a y = delay_1
chave = chave_1
else :
d e l a y = delay_2
chave = chave_2
i f event . added == True :
57
CDIGO DA APLICAO
11.1
#D i c i o n a r i o das c o n e x o e s . Retorna o numero da p o r t a de cada conexao
i f not chave_1 in s e l f . p o r t a s . keys ( ) :

s e l f . p o r t a s . update ({ chave_1 : event . l i n k . port1 })
s e l f . p o r t a s . 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 o p o l o g i a

) or ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] in s e l f . t o p o l o g i a
)):
i f d e l a y == None :
s e l f . d e l a y _ l i n k s . update ({ chave : randrange ( 5 , 8 0 , 5 ) })
s e l f . t o p o l o g i a . append ( [ event . l i n k . dpid1 , s e l f . d e l a y _ l i n k s . g e t ( chave
) , event . l i n k . dpid2 ] )
i f event . removed == True :
i f chave_1 in s e l f . p o r t a s . keys ( ) :
s e l f . p o r t a s . remove ({ chave_1 : event . l i n k . port1 })
s e l f . p o r t a s . 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 o p o l o g i a ) :

s e l f . t o p o l o g 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 o p o l o g i a ) :
s e l f . t o p o l o g i a . remove ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] )
print ' t o p o l o g i a ' , s e l f . t o p o l o g i a

s e l f . count = s e l f . count + 1
# PARA TOPOLOGIA COM 6 ENLACES, O CONTADOR CHEGA A 1 2 .
i f s e l f . count >= 1 2 :
s e l f . dij_1_melhor ,
s e l f . topologia )
s e l f . dij_1_segundo = djakstra_v2 . recebe_dados ( 1 ,

Timer ( 5 , s e l f . _timer_func , r e c u r r i n g=True )

Timer ( 5 , s e l f . l i n k _ t e s t , r e c u r r i n g=True )
def _handle_ConnectionUp ( s e l f , event ) :
58
CDIGO DA APLICAO
11.1
#p r i n t " Entrou ConnectionUP "

#p r i n t "CONECTION " , e v e n t . c o n n e c t i o n
s e l f . c o n n e c t i o n s . add ( event . c o n n e c t i o n )
def handle_flow_stats ( s e l f , event ) :

f l o w _ s t a t s = f l o w _ s t a t s _ t o _ l i s t ( event . s t a t s )
def h a n d l e _ p o r t s t a t s _ r e c e i v e d ( 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 . p o r t a s . g e t ( 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 l o w _ s t a t s _ t o _ l i s t ( event . s t a t s )
def _timer_func ( s e l f ) :
print " Entrou timer_func "
c o r e . openflow . getConnection ( 1 ) . send ( o f . o f p _ s t a t s _ r e q u e s t ( body=o f .
ofp_flow_stats_request ( ) ) )
c o r e . openflow . getConnection ( 1 ) . send ( o f . o f p _ s t a t s _ r e q u e s t ( body=o f .
ofp_port_stats_request ( ) ) )
def l i n k _ t e s t ( s e l f ) :
#A cada 5 s e g u n d o s h a v e r a 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 e n c a apos 10 s e g u n d o s 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 . link_count > 0 :
s e l f . link_count = s e l f . link_count 1
else :
s e l f .LINK_OK = True
else :
i f s e l f . link_count < 5 :
s e l f . link_count = s e l f . link_count + 1
59
CDIGO DA APLICAO
11.1
i f s e l f . link_count >= 2 :
s e l f .LINK_OK = F a l s e
i f s e l f .JA_ENTROU == F a l s e :
msg = o f . ofp_flow_mod ( )
msg . match . dl_type = 0 x800
msg . match . nw_proto = 17
msg . match . nw_dst = IPAddr ( " 1 0 . 0 . 0 . 3 " )
msg . match . tp_dst = 2000
msg . i d l e _ t i m e o u t = 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 . p o r t a s . g e t ( chave2 )
msg . a c t i o n s . append ( o f . ofp_action_output ( p o r t = porta_saida2 ) )
c o r e . openflow . getConnection ( 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 r o t o s r c )
IP_DESTINO = str ( packet . payload . p r o t o d s t )
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 r o t o c o l == packet . payload .TCP_PROTOCOL or packet .

payload . p r o t o c o l == packet . payload .UDP_PROTOCOL:
PORTA_ORIGEM = packet . payload . payload . s r c p o r t
PORTA_DESTINO = packet . payload . payload . d s t p o r t
print "PORTA ORIGEM " , PORTA_ORIGEM

print "PORTA DESTINO " , PORTA_DESTINO
i f IP_DESTINO == " 1 0 . 0 . 0 . 3 " :
60
CDIGO DA APLICAO
11.1
#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 . p o r t a s . g e t ( chave )
e l i f event . dpid == 2 :
#ARP

msg = o f . ofp_packet_out ( )
msg . b u f f e r _ i d = event . ofp . b u f f e r _ i d
msg . a c t i o n s . append ( o f . ofp_action_output ( p o r t = 1) )
else :
msg . a c t i o n s . append ( o f . ofp_action_output ( p o r t = porta_saida ) )
event . c o n n e c t i o n . send ( msg )
else :
i f s e l f .LINK_OK:
msg . match . tp_dst = PORTA_DESTINO
61
CDIGO DA APLICAO
11.1
msg . data = event . ofp
else :
else :
msg . match . tp_dst = PORTA_DESTINO
else :
i f PORTA_DESTINO != 2 0 0 0 :
else :
chave2 = str ( 2 )+str ( 5 )
chave2 = str ( 3 )+str ( 5 )
62
CDIGO DA APLICAO
11.1
chave2 = str ( 4 )+str ( 5 )
msg . a c t i o n s . append ( o f . ofp_action_output ( p o r t = porta_saida2 )
)
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:
#ARP

msg = o f . ofp_packet_out ( )
63
CDIGO DA APLICAO
11.1
msg . a c t i o n s . append ( o f . ofp_action_output ( p o r t = porta ) )
else :
else :
i f s e l f .LINK_OK:
msg . match . nw_dst = IPAddr (IP_DESTINO)
else :
else :
msg . match . nw_dst = IPAddr (IP_DESTINO)
msg . match . tp_src = PORTA_ORIGEM
64
CDIGO DA APLICAO
11.1
else :
i f (PORTA_ORIGEM != 2000) :
else :
chave2 = str ( 2 )+str ( 1 )
chave2 = str ( 3 )+str ( 1 )
chave2 = str ( 4 )+str ( 1 )
msg . a c t i o n s . append ( o f . ofp_action_output ( p o r t = porta_saida2 )
)
def launch ( ) :
c o r e . r e g i s t e r N e w ( switch_multi )
Cdigo 11.1: Cdigo app.py em Python, aplicao que realiza a troca dinmica das rotas
considerando a utilizao do link principal
65
Referncias bibliogrcas
Cai et al. (2010) Zheng Cai, Alan L. Cox e T.S. Eugene Ng.
Maestro: A system for scalable
openow control. Citado na(s) pg(s).: 32
Central () SDN Central.
Documentation. http://www.sdncentral.com/. ltimo acesso em
Maio/2014. Citado na(s) pg(s).:
Comer (2013)
Douglas E. Comer.
and Architecture.
Internetworking with TCP/IP - Principals, Protocols
Pearson, 6 edio. ISBN 9780136085300. Citado na(s) pg(s).: 6, 9, 10, 11,
13, 15, 16, 18, 19, 27
Erickson (2013) David Erickson.

Farrel (2004)
Adrian Farrel.
The beacon openow controller. Citado na(s) pg(s).: 32
A Internet e seus protocolos.
Campus Elsevier, 1 edio.
ISBN 9788535266917. Citado na(s) pg(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) pg(s).: 2, 18
Filho (2013) Joo Eriberto Mota Filho. Anlise de trfego em redes TCP/IP.
Novatec, 1
edio. ISBN 9788575223758. Citado na(s) pg(s).: 7
Foundation (2009)
ONF Open Network Foundation. Openow switch specication, ver-
sion 1.0.0. Citado na(s) pg(s).: 24, 25, 26, 28
Foundation (2011a)
ONF Open Network Foundation.
Openow switch specication,
version 1.1.0. Citado na(s) pg(s).: 29, 30
Foundation (2011b)
version 1.2. Citado na(s) pg(s).: 30
Foundation (2012a)
version 1.3.0. Citado na(s) pg(s).: 31
Foundation (2012b)
version 1.4.0. Citado na(s) pg(s).: 31
Google (2012)
Google. Inter-datacenter wan with centralized te using sdn and openow,
2012. Citado na(s) pg(s).: 21
Gude et al. (2008)
Natasha Gude, Ben Pfa, Teemu Koponen, Martn Casado, Scott
Shenker, Justin Pettit e Nick McKeown. Nox: Towards an operating system for networks.
Citado na(s) pg(s).: 32
66
REFERNCIAS BIBLIOGRFICAS
11.1
Handigol et al. (2012)
67
Nikhil Handigol, Brandon Heller, Vimalkumar Jeyakumar, Bob
Lantz e Nick McKeown. Reproducible network experiments using container-based emulation. Citado na(s) pg(s).: 35
Heller (2013)
tion.
Brandon Heller.
Reproducible Network Research with High-Fidelity Emula-
Tese de Doutorado. Citado na(s) pg(s).: 33, 35
http://archive.openow.org/wp/learnmore/ () http://archive.openow.org/wp/learnmore/.
Documentation. http://archive.openow.org/wp/learnmore/. ltimo acesso em Maio de
2014. Citado na(s) pg(s).:
https://openow.stanford.edu/display/ONL/POX+Wiki
https://openow.stanford.edu/display/ONL/POX+Wiki.
//openow.stanford.edu/display/ONL/POX+Wiki.
()
Pox
wiki.
https:
ltimo acesso em Novembro de
2014. Citado na(s) pg(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) pg(s).: 32
http://www.noxrepo.org/pox/about pox/ ()
http://www.noxrepo.org/pox/about
pox/. About pox. http://www.noxrepo.org/pox/about-pox/. ltimo acesso em Novembro

de 2014. Citado na(s) pg(s).: 32
iperf.fr ()
iperf.fr. Documentation. http://iperf.fr/. ltimo acesso em Maio/2014. Citado
na(s) pg(s).: 40
Kurose e Ross (2010)
James F. Kurose e Keith W. Ross.
Internet: Uma abordagem top-down.
Redes de Computadores e a
Pearson, 5 edio. ISBN 9788588639973. Citado na(s)
pg(s).:
Lantz e O'Connor () Bob Lantz e Brian O'Connor.
Mininet: An instant virtual network
on your laptop. Citado na(s) pg(s).: 33, 34
Lantz et al. (2010)
Bob Lantz, Brandon Heller e Nick McKeown. A network in a laptop:
Rapid prototyping for software-dened networks. Citado na(s) pg(s).: 33, 35
Lara et al. (2014) Adrian Lara, Anisha Kolasani e Byrav Ramamurthy. Network innovation
using openow: A survey. Citado na(s) pg(s).: 22, 30
McKeown (2011) Nick McKeown.
How sdn will shape networking, 2011. Citado na(s) pg(s).:
20
McKeown et al. (2008)
Nick McKeown, Guru Parulkar, Tom Anderson, Larry Peterson,
Scott Shenker, Jonathan Turner, Hari Balakrishnan e Jennifer Rexford. Openow: Enabling innovation in campus networks. Citado na(s) pg(s).: 2, 23
mininet.org () mininet.org.
Documentation. http://mininet.org/. ltimo acesso em Maio
de 2014. Citado na(s) pg(s).:
Nunes et al. (2014) Bruno Astuto A. Nunes, Marc Mendona, Xuan-Nam Nguyen, Katia
Obraczka e Thierry Turletti. A survey of software-dened networking: Past, present ad
future of programmable networks. Citado na(s) pg(s).: 17, 19, 32
Opennetworking ()
Opennetworking.
Documentation.
org/. ltimo acesso em Maio/2014. Citado na(s) pg(s).:
https://www.opennetworking.
REFERNCIAS BIBLIOGRFICAS
11.1
Postel (1981) Jon Postel.
68
Rfc 791 - internet protocol, 1981. Citado na(s) pg(s).:
Tanenbaum (2012) Andrew Stuart Tanenbaum. Redes de computadores. Pearson, 5 edio.

ISBN 978876059240. Citado na(s) pg(s).:
Wikipdia ()
Wikipdia.
Software-dened networking.
http://en.wikipedia.org/wiki/
Software-dened_networking. ltimo acesso em Maio/2014. Citado na(s) pg(s).:
Yamamoto e Scharra (2014) Kazuo Yamamoto e Marcus Scharra.
Fundamentals of sdn
in 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) pg(s).: 21

Desenvolvimento de Uma Aplicação para Diferenciação de Caminhos em Redes Definidas Por Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desenvolvimento de Uma Aplicação para Diferenciação de Caminhos em Redes Definidas Por Software

Uploaded by

Copyright:

Available Formats

Elton Gastardelli Kleis

Desenvolvimento de uma aplicao

Niteri, 2 de dezembro de 2014

Elton Gastardelli Kleis

Desenvolvimento de uma aplicao

do ttulo de Bacharel em Engenharia

Niteri, 2 de dezembro de 2014

Elton Gastardelli Kleis

Desenvolvimento de uma aplicao

Aprovado em: 10 de Dezembro de 2014

Prof. Dr. Ricardo Campanha Carrano

Prof. Dr. Joo Marcos Meirelles da Silva

Prof. Dra. Natalia Castro Fernandes

Elton Gastardelli Kleis

Keywords: SDN, Software-Dened Networking, Programmable Networks, POX, Mininet

As quatro camadas do modelo TCP/IP. . . . . . . . . . . . . . . . . . . . . .

Em (a) tem-se a viso do usurio da rede e em (b) a estrutura fsica com os

Cabealho do protocolo IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . .

Algoritmo executado pelo roteador ao receber um pacote

Ilustrao do aprendizado de rotas pelo roteador e distino entre as bases de

Em (a), tabela de encaminhamento presente no roteador  `Y. (b) ilustra uma

Troca de rtulos realizada por cada dispositivo . . . . . . . . . . . . . . . . .

Planos de controle e dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Congurao bsica SDN, com um controlador externo congurando o dispositivo de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Representao de uma rede genrica.

Switch OpenFlow idealizado. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Entrada da tabela de uxos. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lista dos contadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fluxograma do processamento dos pacotes. . . . . . . . . . . . . . . . . . . .

Tipos de mensagens para modicao da tabela de uxos.

Componentes de um switch OpenFlow 1.1

Fluxograma detalhando o uxo de pacotes atravs do switch OpenFlow 1.1 .

Alguns controladores OpenFlow existentes

Topologia simples com dois hosts e um switch. . . . . . . . . . . . . . . . . .

Virtualizao completa dos dispositivos.

Virtualizao "leve"dos dispositivos. . . . . . . . . . . . . . . . . . . . . . . .

Fluxograma representando primeira etapa da execuo da aplicao. . . . . .

Pacotes ARP e respota do controlador. . . . . . . . . . . . . . . . . . . . . .

Resposta do controlador para outros pacotes. . . . . . . . . . . . . . . . . . .

Fluxograma representando o evento de Packet-In.

Fluxograma do teste de links e chaveamento entre caminhos. . . . . . . . . .

Topologia utilizada nos testes. . . . . . . . . . . . . . . . . . . . . . . . . . .

Comandos do Iperf nos clientes. . . . . . . . . . . . . . . . . . . . . . . . . .

Comandos do Iperf no servidor.

Percentual da perda de pacotes com os uxos sendo enviados sempre por

Teste com dois hosts enviando por caminhos diferentes. . . . . . . . . . . . .

Percentual da perda de pacotes com ambos os uxos sendo enviados sempre

pelo melhor caminho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Teste com dois hosts enviando pelo mesmo caminho.

7.10 Percentual da perda dos pacotes, realizando a mudana de rota dinamicamente. 45

7.12 Tabela de uxos do switch 1. . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.13 Percentual mdio dos erros . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.14 Taxa de transmisso mdia . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Conceitos bsicos das redes de computadores

Protocolos do tipo vetor distncia . . . . . . . . . . . . . . . . . . . .

Protocolos do tipo estado de enlace . . . . . . . . . . . . . . . . . . .

Comutao baseada em rtulos

3 SDN - Redes Denidas por Software

Um novo paradigma em redes de computadores

Composio dos switches OpenFlow . . . . . . . . . . . . . . . . . . . . . . .

Cdigo para criao da topologia

Advanced Research Projects Agency Network ),

que buscava interligar as bases militares e

Keywords: SDN, Software-Dened Networking, Programmable Networks, POX, Mininet

Em (a), tabela de encaminhamento presente no roteador `Y. (b) ilustra uma

Congurao bsica SDN, com um controlador externo congurando o dispositivo de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Entrada da tabela de uxos. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tipos de mensagens para modicao da tabela de uxos.

Fluxograma detalhando o uxo de pacotes atravs do switch OpenFlow 1.1 .

Percentual da perda de pacotes com os uxos sendo enviados sempre por

Percentual da perda de pacotes com ambos os uxos sendo enviados sempre

7.12 Tabela de uxos do switch 1. . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 SDN - Redes Denidas por Software

et al. , 2008). Nesse cenrio, surgem as redes denidas

amplamente difundido e aceito. As redes denidas por software vm apresentando grande

Apresentar conceitos do OpenFlow, implementao mais difundida das redes denidas

identicao de cada mquina (endereamento fsico) em uma rede local. O ARP (

orientada a conexes. Nesse trabalho, quando no especicado o contrrio, o texto estar

best-eort ) e com entrega de

Cada entrada na tabela de roteamento identicar a rede de destino, o roteador usado

gem de atualizao do roteador X que ir causar mudanas em Y

2.5.1 Classicao de pacotes