desenvolvimento de uma aplicação para diferenciação de caminhos em redes definidas por software

Elton Gastardelli Kleis

Desenvolvimento de uma aplicação

para diferenciação de caminhos em redes

definidas por software

Niterói, 2 de dezembro de 2014





Trabalho apresentado ao Curso de

Engenharia de Telecomunicações da

Universidade Federal Fluminense -

UFF, como requisito para obtenção

do título de Bacharel em Engenharia

de Telecomunicações.

Orientadora: Prof. Dra. Natalia

Castro Fernandes






Trabalho apresentado ao Curso de

Engenharia de Telecomunicações da

Universidade Federal Fluminense -

UFF, como requisito para obtenção

do título de Bacharel em Engenharia

de Telecomunicações.

Aprovado em: 10 de Dezembro de 2014

Comissão julgadora:

Prof. Dr. Ricardo Campanha Carrano Prof. Dr. João Marcos Meirelles da Silva

Prof. Dra. Natalia Castro Fernandes


Agradecimentos

Primeiramente gostaria de agradecer à minha família, à meu pai Samuel, meu irmão

Natan e principalmente à minha mãe Sandra e ao meu avô Pedro (in memoriam) pelo

amor, carinho e por terem sempre me apoiado e acreditado no meu potencial. Gostaria de

agradecer também a minha namorada Patricia, que desde o ensino médio esteve ao meu lado,

comemorando comigo os bons momentos e me apoiando nos maus. Gostaria de agradecer

aos professores, Natalia Fernandes, Ricardo Carrano, Tadeu Nagashima, Gilberto Ferreira,

e a todos os outros que me ajudaram na busca do conhecimento. Agradeço também ao

professor Márcio Albuquerque (CBPF) por todo o apoio e conselhos e ao Luís Henrique

Rosati Rocha (BNDES) pelo exemplo de caráter e pro�ssionalismo. Agradeço a todos meus

amigos que direta ou indiretamente contribuíram para minha formação, principalmente ao

Alan Henrique Ferreira, Gabriel Oliveira e ao Rogério Libarino. A todos vocês, meu muito

obrigado!


i

Resumo

Nessa monogra�a, é apresentado um novo paradigma em redes de computadores, as redes

de�nidas por software.

Esse conceito surgiu em universidades americanas em meados de 2008 e propõe a retirada

da �inteligência� dos dispositivos de redes como switches e roteadores. Essa �inteligência�

seria concentrada em um controlador, entidade com total visão e controle da rede.

Em redes de�nidas por software, têm-se uma maior �exibilidade, já que se pode criar

diversas aplicações, programando o controlador da rede. Aplicações que hoje seriam impensá-

veis começarão a ser desenvolvidas com facilidade. Diante desse novo paradigma em redes de

computadores, uma aplicação simples desenvolvida em Python é apresentada. Essa aplicação

altera o caminho de um determinado �uxo mediante a uma circunstância pré-estabelecida.

A mesma foi testada utilizando o emulador Mininet e alguns resultados de desempenho

são apresentados.

Palavras-chave: SDN, Redes de�nidas por software, Redes programáveis, POX, Mininet.

ii

Abstract

In this monograph, a new computer networks' paradigm is presented, Software-De�ned

Networking.

This concept was born in American universities around 2008 proposing removal of the

�intelligence� in networks devices such as switches and routers. This �intelligence� would be

centralized in a controller, an entity with total view and control of the network. Due this

fact, Software-De�ne Networking is more �exible, considering the fact that it is possible to

create several applications, simply programming the network controller. Applications that

are unthinkable nowadays, would be developed easily.

Thinking about this new computer networks' paradigm, a simple application that was

developed in Python language is introduced on this monograph. This application consists

on changing the path of a speci�c data �ow according a pre-established condition.

The application was tested using Mininet emulator and the performance results will be

discussed on the present work.

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

iii

Lista de �guras

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

2.2 Em (a) tem-se a visão do usuário da rede e em (b) a estrutura física com os

enlaces e roteadores representados. . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Cabeçalho do protocolo IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Algoritmo executado pelo roteador ao receber um pacote . . . . . . . . . . . 10

2.5 Ilustração do aprendizado de rotas pelo roteador e distinção entre as bases de

informações de roteamento e de encaminhamento . . . . . . . . . . . . . . . 12

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

mensagem de atualização do roteador �X� que irá causar mudanças em �Y� . 13

2.7 Troca de rótulos realizada por cada dispositivo . . . . . . . . . . . . . . . . . 15

3.1 Planos de controle e dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Con�guração básica SDN, com um controlador externo con�gurando o dispo-

sitivo de rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Representação de uma rede genérica. . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Switch OpenFlow idealizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Entrada da tabela de �uxos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Campos de cabeçalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.4 Lista dos contadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Fluxograma do processamento dos pacotes. . . . . . . . . . . . . . . . . . . . 26

4.6 Tipos de mensagens para modi�cação da tabela de �uxos. . . . . . . . . . . 28

4.7 Componentes de um switch OpenFlow 1.1 . . . . . . . . . . . . . . . . . . . 29

4.8 Fluxograma detalhando o �uxo de pacotes através do switch OpenFlow 1.1 . 30

4.9 Alguns controladores OpenFlow existentes . . . . . . . . . . . . . . . . . . . 32

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

5.2 Virtualização completa dos dispositivos. . . . . . . . . . . . . . . . . . . . . 34

5.3 Virtualização "leve"dos dispositivos. . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 Pacotes LLDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Fluxograma representando primeira etapa da execução da aplicação. . . . . . 37

6.3 Pacotes ARP e respota do controlador. . . . . . . . . . . . . . . . . . . . . . 37

iv

LISTA DE FIGURAS v

6.4 Resposta do controlador para outros pacotes. . . . . . . . . . . . . . . . . . . 38

6.5 Fluxograma representando o evento de Packet-In. . . . . . . . . . . . . . . . 38

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

7.1 Topologia utilizada nos testes. . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.2 Inicialização do Mininet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.3 Inicialização da aplicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.4 Comandos do Iperf nos clientes. . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.5 Comandos do Iperf no servidor. . . . . . . . . . . . . . . . . . . . . . . . . . 42

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

caminhos diferentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

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

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

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

7.9 Teste com dois hosts enviando pelo mesmo caminho. . . . . . . . . . . . . . 44

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

7.11 Resultado do primeiro teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

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

7.13 Percentual médio dos erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.14 Taxa de transmissão média . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Lista de acrônimos

API - Application Programming Interface

ARP - Address Resolution Protocol

ARPANET - Advanced Research Projects Agency Network

AS - Autonomous System

ATM - Asynchronous Transfer Mode

BYOD - Bring Your Own Device

CBE - Content-Based Emulation

CIDR - Classless Inter-Domain Routing

CLI - Command Line Interface

EGP - Exterior Gateway Protocol

EIGRP - Enhanced Interior Gateway Routing Protocol

FIB - Forwarding information base

LSA - Link State Advertisement

LLDP - Link Layer Discovery Protocol

LSP - Link State Packet

IGP - Interior Gateway Protocol

IP - Internet Protocol

ISP - Internet Service Provider

MAC - Media Access Control

MPLS - Multiprotocol Label Switching

OSPF - Open Shortest Path First

ONF - Open Network Foundation

QoS - Quality of Service

RIB - Routing Information Base

RIP - Routing Information Protocol

SDN - Software-De�ned Networking

SSL - Secure Sockets Layer

TCP - Transmission Control Protocol

TLS - Transport Layer Security

ToS - Type of Service

UDP - User Datagram Protocol

VoIP - Voice over IP

vi

Sumário

Lista de �guras iv

1 Introdução 1

1.1 Motivação e objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Conceitos básicos das redes de computadores 4

2.1 Modelo em camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Endereçamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Máscara de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Encaminhamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Protocolos do tipo vetor distância . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Protocolos do tipo estado de enlace . . . . . . . . . . . . . . . . . . . 14

2.5 Comutação baseada em rótulos . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.1 Classi�cação de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 SDN - Redes De�nidas por Software 17

3.1 Engenharia de Tráfego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Um novo paradigma em redes de computadores . . . . . . . . . . . . . . . . 18

4 OpenFlow 22

4.1 Composição dos switches OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Tabela de �uxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 O canal seguro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Outras versões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.1 OpenFlow 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4.2 OpenFlow 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.3 OpenFlow 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.4 OpenFlow 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 POX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Mininet 33

vii

SUMÁRIO viii

6 A aplicação desenvolvida 36

6.1 Executando a aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Simulação e resultados 40

7.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8 Conclusões 48

9 Apêndice A 50

9.1 Código para criação da topologia . . . . . . . . . . . . . . . . . . . . . . . . 50

10 Apêndice B 52

10.1 Código para calcular as rotas . . . . . . . . . . . . . . . . . . . . . . . . . . 52

11 Apêndice C 56

11.1 Código da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Referências bibliográ�cas 66

Capítulo 1

Introdução

As redes de computadores nos permitem fazer coisas inimagináveis há poucas décadas.

Seu embrião teve início no �nal da década de 1960 com a então denominada ARPANET

(Advanced Research Projects Agency Network), que buscava interligar as bases militares e

os departamentos de pesquisa norte americanos. Muito evolui desde então. Modelos para

protocolos de comunicação foram criados e muitos protocolos foram desenvolvidos, sejam

para suprir a demanda de aplicações, sejam para calcular os caminhos que os pacotes devem

percorrer ao longo da rede.

Devido à essa evolução de ideias, desde o início das pesquisas sobre comutação de pacotes

e da ARPANET, juntamente com a evolução do hardware utilizado, hoje temos inúmeras

possibilidades na rede. Anexar enormes quantidades de arquivos em nossos e-mails, jogar

jogos com pessoas do mundo inteiro em tempo real, ou até mesmo realizar ligações telefônicas

através da Internet.

Entretanto, talvez hoje as redes estejam na iminência de uma mudança de paradigma,

mudança essa que possibilitará o desenvolvimento de aplicações cuja implementação com

a tecnologia atual seria impossível. Com a utilização de redes de�nidas por software (SDN

- Software-De�ned Networking), será possível um total controle da rede. Não haverá mais

a necessidade de hardwares especializados, mas sim, poderá se utilizar hardwares genéricos

programáveis. Novos protocolos poderão ser testados e implementados com uma rapidez

nunca antes vista e aplicações que hoje são impensáveis se tornarão absolutamente viáveis

através da implementação dessa tecnologia.

1

1.1 MOTIVAÇÃO E OBJETIVOS 2

1.1 Motivação e objetivos

Atualmente, as redes de computadores se tornaram parte essencial da infraestrutura

de nossa sociedade. Hoje, inúmeras aplicações �rodam� sobre a Internet, aplicações essas

que não foram imaginadas no projeto inicial das redes de computadores. Com o objetivo de

suportar o número crescente de aplicações e usuários, diversos �remendos� foram sendo feitos

ao longo dos anos. Entretanto, substancialmente, o núcleo da rede se manteve o mesmo. Os

softwares de switches e roteadores não podem ser reprogramados e novas ideias e protocolos

não podem ser testados em uma rede em produção, fato esse denominado por alguns autores

como �ossi�cação� da rede (McKeown et al. , 2008). Nesse cenário, surgem as redes de�nidas

por software.

O conceito de redes programáveis não é novo. Como exemplo, tem-se o conceito de redes

ativas na década de 1990 (Feamster et al. , 2014). Entretanto, pela primeira vez, o conceito

é amplamente difundido e aceito. As redes de�nidas por software vêm apresentando grande

aceitação por parte da comunidade acadêmica e pelos principais fabricantes de equipamentos,

que já começaram a desenvolver soluções voltadas para esse modelo.

Diante o exposto, como objetivo geral, essa monogra�a pretende apresentar ao leitor

esse novo paradigma em redes de computadores, mostrando o quão importante o mesmo

será para pesquisadores que necessitam testar novos protocolos assim como para gestores

que precisam gerenciar redes de computadores todos os dias.

Para tal, os seguintes objetivos especí�cos devem ser atingidos:

• Apresentação dos conceitos básicos das redes de computadores atuais, fornecendo um

conhecimento mínimo para aqueles que não estejam familiarizados com redes de com-

putadores;

• Abordar conceitos como plano de controle e de dados, e sua separação nas redes de�-

nidas por software;

• Apresentar conceitos do OpenFlow, implementação mais difundida das redes de�nidas

por software;

• Apresentação de uma aplicação programada em Python, para redes de�nidas por soft-

ware. Essa aplicação altera o caminho de um �uxo pré-estabelecido, mediante a uma

alta utilização da largura de banda do caminho principal;

1.2 ORGANIZAÇÃO DO TRABALHO 3

1.2 Organização do trabalho

Essa monogra�a está estruturada como mostrado a seguir.

No Capítulo 2, serão apresentados conceitos de redes de computadores básicos para que

seja possível o entendimento posterior das redes de�nidas por software. O mesmo tratará de

assuntos como o modelo de camadas TCP/IP, endereçamento, encaminhamento de pacotes

e comutação baseada em rótulos.

O Capítulo 3 tratará dos conceitos básicos sobre planos de controle e de dados e, sequen-

cialmente, da de�nição de redes de�nidas por software.

No Capítulo 4, será apresentado o padrão/protocolo OpenFlow. Os switches OpenFlow

serão de�nidos e suas características como tabela de �uxos e o canal seguro serão explana-

das. Também são apresentados nesse capítulo os principais controladores disponíveis, dando

enfoque ao POX, controlador utilizado.

O Mininet, emulador de redes utilizado nesse trabalho, é apresentado e suas caracterís-

ticas explicadas no Capítulo 5.

No Capítulo 6 uma descrição detalhada da aplicação desenvolvida será apresentada. Já

no Capítulo 7 são apresentados os resultados dos testes feitos, veri�cando como o uso da

aplicação reduziu a perda de pacotes.

As conclusões são apresentadas no Capítulo 8 e nos capítulos seguintes os códigos utili-

zados para o experimento podem ser encontrados.

Capítulo 2

Conceitos básicos das redes de

computadores

Nesse capítulo, serão abordados conceitos como modelo de camadas TCP/IP, endere-

çamento, encaminhamento e classi�cação de pacotes. Conceitos esses fundamentais para o

pleno entendimento das vantagens e desvantagens das redes de�nidas por software.

2.1 Modelo em camadas

As redes de computadores atuais, em sua maioria, seguem o modelo denominado TCP/IP

(Transmission Control Protocol / Internet Protocol). O modelo apresenta um conjunto de

protocolos para comunicação entre dispositivos. Esses protocolos são organizados de acordo

com uma pilha de camadas, onde cada camada irá oferecer serviços para as camadas superio-

res. Essa divisão em camadas, ao reduzir a complexidade, facilita a implementação de novas

tecnologias, permitindo também a interconectividade entre sistemas. A Figura 2.1 apresenta

o modelo TCP/IP de 4 camadas.

Figura 2.1: As quatro camadas do modelo TCP/IP.

4

2.1 MODELO EM CAMADAS 5

Na camada de aplicação, o nível mais alto do modelo, usuários utilizam programas que

acessam serviços disponíveis através da rede TCP/IP. A aplicação irá interagir com pro-

tocolos da camada de transporte para enviar e receber dados. Como será visto adiante, o

modelo foi concebido para que todas as outras camadas sejam transparentes para o usuário

�nal, ou seja, o mesmo não precisa ter conhecimento sobre a implementação das camadas

subjacentes.

A principal função da camada de transporte é prover uma comunicação ponto-a-ponto,

ou seja, conectando uma aplicação de um dispositivo origem com uma aplicação em um

dispositivo destino, independentemente da quantidade de equipamentos intermediários. Com

isso, a camada transporte deve aceitar dados provenientes de diversas aplicações, encapsulá-

los, incluindo informações que serão utilizadas para controle e para identi�cação da aplicação

de origem e destino e enviar esses dados encapsulados para as camadas mais baixas.

A camada de transporte pode também regular o �uxo de informações, podendo inclusive

oferecer um transporte con�ável, como por exemplo, veri�cando periodicamente a conexão

estabelecida e assegurando que os dados estão sendo enviados e recebidos corretamente,

chegando sem erros. São exemplos de protocolos dessa camada, o UDP (Datagram Protocol)

e o TCP.

A camada de internet lida com a comunicação de um dispositivo a outro, aceitando

pedidos de envio de pacotes da camada de transporte. A mesma irá encapsular os dados da

camada de transporte em um pacote IP, preenchendo o cabeçalho com diversas informações,

inclusive com o endereço lógico de origem (IP de origem) e o endereço lógico de destino (IP

de destino).

A camada de internet também é responsável por encaminhar esses pacotes para a camada

de acesso à rede, onde os mesmos serão encaminhados diretamente para o destino (podendo

vir a passar por dispositivos como switches e hubs), se os hosts estiverem na mesma rede.

Caso não estejam, como duas redes diferentes não se �enxergam� os pacotes devem ser

enviados para equipamentos que fazem a interligação entre redes, denominados roteadores.

Através dos roteadores os pacotes podem ser encaminhados por redes intermediárias, até

chegarem ao destino �nal. A camada de internet também é responsável por lidar com os

pacotes IP's recebidos, checando sua validade e veri�cando se os mesmos são destinados para

um host na rede local ou se devem ser encaminhados para outras redes. Maiores detalhes

sobre a camada de rede serão vistos na seção sobre encaminhamento.

A camada de acesso à rede de�ne as regras de acesso ao meio físico de�nindo o ende-

reçamento físico e os protocolos necessários para essa transmissão. Além disso, converte os

dados vindos da camada superior (internet) em sinais elétricos/ópticos, tornando possível a

transmissão em cabos e �bras ópticas.

É importante entender que para a camada de internet não importa a localização física das

máquinas, mas a localização lógica das redes. A camada de acesso à rede, é responsável pela

identi�cação de cada máquina (endereçamento físico) em uma rede local. O ARP (Address

Resolution Protocol), protocolo da camada de rede, fará a tradução do endereço lógico para

2.2 ENDEREÇAMENTO 6

o endereço físico, quando o pacote de dados já estiver na rede de destino.

Para �nalizar, as redes em camadas são projetadas de modo que uma determinada ca-

mada no destino receba exatamente os mesmos objetos enviados pela mesma camada cor-

respondente na origem, ou seja, os mesmos dados enviados pela camada de aplicação na

origem, devem ser os mesmos dados recebidos pela camada de aplicação no destino.

As redes de computadores em geral, sobretudo a Internet, foram projetadas para prover

uma interconexão universal entre computadores independentemente das particularidades da

rede aos quais estejam conectados, tornando-se transparente para o usuário, que a vê como

uma única rede virtual (como pode ser visto na Figura 2.2), a qual todas as máquinas estão

conectadas. Essa virtualização será importante para o entendimento das redes de�nidas por

software.

Figura 2.2: Em (a) tem-se a visão do usuário da rede e em (b) a estrutura física com os enlacese roteadores representados.

Fonte: Comer (2013)

2.2 Endereçamento

Sendo a camada de internet uma das mais importantes do modelo TCP/IP, torna-se

interessante o entendimento da divisão e endereçamento lógicos dos dispositivos, assim como

também é interessante entender como ocorre o roteamento e encaminhamento dos pacotes.

Em uma rede TCP/IP, cada adaptador de rede existente em um dispositivo é identi�cado

por um número chamado endereço IP. Tomando-se como base o IP versão 4, esse endereço IP

consiste em quatro conjuntos de 8 bits. Esses octetos, quando representados, são separados

por pontos.

2.2 ENDEREÇAMENTO 7

Um exemplo de endereço IP segue abaixo:

00001010.00000000.00000000.00000001

Dessa forma, todos os 32 bits são representados. Entretanto, a forma mais usual de

representação do endereço IP, é a decimal. O mesmo endereço IP representado acima, pode

ser escrito como:

10.0.0.1

Dito isso, pode-se concluir que o menor octeto possível é o 00000000 (0 em decimal) e o

maior octeto possível é o 11111111 (255 em decimal), ou seja, cada octeto pode variar de 0

a 255.

Parte do endereço IP será utilizada para representar a rede a qual o dispositivo está

conectado e a outra parte será utilizada para representar o dispositivo em si.

2.2.1 Máscara de rede

A máscara de rede é um recurso utilizado para segmentar redes logicamente. Com esse

recurso, pode-se ter várias redes lógicas diferentes disponíveis no mesmo espaço físico, ou

ainda, pode-se ter uma única rede lógica em mais de uma localidade física.

Essa rede lógica pode ser entendida como conjuntos independentes de dispositivos (com-

putadores, impressoras, switches) conectados à rede em um determinado espaço físico. As

divisões em redes lógicas diferentes são feitas justamente com base no endereço IP e na

máscara de rede.

A máscara de rede é de�nida como um conjunto de 32 bits divididos em quatro octetos,

assim como o endereço IP. Entretanto, algumas regras são levadas em consideração na criação

da máscara de rede Filho (2013):

• Não pode haver a mistura de algarismos 0 e 1;

• Não pode haver algarismo 0 antes de algarismo 1;

Segue abaixo um exemplo de máscara de rede, com os bits representados e também na

forma decimal:

11111111.00000000.00000000.00000000

255.0.0.0

Essa máscara de rede será comparada com o endereço IP. Os bits que forem 1 na máscara

de rede representam a porção da rede no endereço IP e os bits que forem 0 representam o

dispositivo.

Logo, pegando-se o endereço IP do exemplo acima e analisando-o com o exemplo de

máscara de rede, tem-se que os oito primeiros bits do endereço IP são referentes à rede, ou

seja, o valor �10�. Já os �.0.0.1� representam o dispositivo dessa rede.

A notação usual, a notação CIDR (Classless Inter-Domain Routing), é a representação

do endereço IP, seguido de uma barra (/) e da quantidade de bits que são correspondentes

à porção de rede.

2.3 ENCAMINHAMENTO 8

Logo, como foram utilizados oito bits para a máscara de rede acima, temos a seguinte

notação:

10.0.0.1/8

Um outro exemplo segue abaixo:

IP : 11000000.10101000.00000000.00000001 = 192.168.0.1

Máscara: 11111111.11111111.11111111.00000000 = 255.255.255.0

Notação CIDR: 192.168.0.1/24

Logo, os 24 primeiros bits representam a porção do IP destinado à rede e os últimos 8 bits

representam o dispositivo daquela rede. Para representar o endereço de rede, completa-se a

parte do endereço IP referente ao dispositivo com bits zero.

Logo para os dois exemplos apresentados têm-se as redes:

10.0.0.0/8

192.168.0.0/24

Os conceitos de máscaras de rede e de endereço de rede são importantes, pois os mesmos

serão utilizados nos roteadores para a realização do encaminhamento que será abordado a

seguir.

2.3 Encaminhamento

Para que o conceito de encaminhamento de pacotes em redes de computadores atuais

possa ser compreendido, é importante diferenciar-se os tipos de serviços que a camada de

internet pode oferecer.

A camada de internet oferece dois tipos distintos de serviços. O serviço orientado a

conexão e o serviço não orientado a conexão. As redes orientadas a conexões são denominadas

redes de circuitos virtuais. Como exemplos, têm-se as redes ATM (Asynchronous Transfer

Mode) e Frame Relay. Já a Internet é uma rede de datagramas, ou seja, uma rede não

orientada a conexões. Nesse trabalho, quando não especi�cado o contrário, o texto estará

tratando das redes não orientadas a conexões.

O serviço de entregas oferecido pela camada de rede em uma rede de datagramas, como

a Internet, pode ser de�nido como incerto, de melhor esforço (best-e�ort) e com entrega de

pacotes sem conexão.

O serviço é incerto, pois a entrega de pacotes não é garantida. Os pacotes podem ser

perdidos, duplicados, podem chegar atrasados ou até mesmo fora de ordem. O serviço é dito

de melhor esforço, porque os pacotes tentarão ser entregues, entretanto não há garantias.

Não há garantia de largura de banda e nem mesmo indicações de congestionamento.

Finalmente o serviço também é de�nido como sem conexão, pois cada pacote é tratado

independentemente. Uma sequência de pacotes enviados de um dispositivo a outro, podem

trafegar por diferentes caminhos. Não existe um circuito pré-de�nido como existe, por exem-

plo, nas redes de circuitos virtuais. Uma exceção seria a tecnologia MPLS (Multiprotocol Label


Switching) que será abordada posteriormente.

O protocolo IP, um dos mais importantes do modelo TCP/IP, apresenta todas as carac-

terísticas supracitadas e ainda:

• De�ne a unidade básica de dados que será transmitida através da rede TCP/IP, espe-

ci�cando o formato dos pacotes utilizados por todos os dados.

• O IP de�ne uma série de regras, como por exemplo, como dispositivos e roteadores de-

vem processar os pacotes e as condições sob as quais os pacotes podem ser descartados.

Comer (2013)

Apenas a título de ilustração, segue na Figura 2.3 o formato do cabeçalho IPv4.

Figura 2.3: Cabeçalho do protocolo IPv4

Fonte: RFC 791

Conforme dito anteriormente, a transmissão de datagramas IP entre dois dispositivos em

uma única rede física, não envolverá o uso de roteadores. O dispositivo que está enviando

os dados encapsulará o datagrama em um quadro, vinculará o endereço do próximo salto ao

endereço físico do dispositivo de destino e enviará o quadro resultante para o dispositivo de

próximo salto.

Caso o dispositivo não esteja na mesma rede, o protocolo selecionará o próximo roteador

para onde o pacote deve ser enviado. Esse processo se repete até que o pacote chegue a um

roteador que possa entregar o pacote diretamente para o dispositivo de destino.

Com o objetivo de descobrir se o dispositivo de destino se encontra conectado em uma

de suas redes, o roteador realiza um teste simples. Como foi visto, o endereço IP é dividido

em duas partes, uma que irá identi�car a rede e outra que irá identi�car o dispositivo.

Logo, ao receber o quadro, o roteador desencapsula o pacote e compara os bits referentes

à identi�cação da rede do endereço IP do dispositivo destino com o endereço de rede dos

endereços IP's de suas interfaces. Uma equivalência signi�ca que o dispositivo destino se

encontra na rede ligada a essa interface. Esse teste é computacionalmente e�ciente, pois

requer apenas algumas instruções de máquina.

O encaminhamento dos pacotes é do tipo próximo salto, ou seja, o roteador que acabou

de receber o pacote, não precisa saber quais são todos os saltos intermediários que o pacote


deverá percorrer até chegar ao destino. Precisa saber apenas qual é o próximo salto, e para

isso, o mesmo irá veri�car sua tabela de encaminhamento (FIB - Forwarding information

base).

Se todos os roteadores da internet precisassem ter em suas tabelas de encaminhamento

todos os IP's disponíveis, os mesmo precisariam de uma enorme quantidade de memória além

de que, a cada alteração de rota os roteadores precisariam reescrever inúmeras entradas.

Entretanto, as tabelas de encaminhamento precisam conter apenas o endereço das redes, ou

seja, o pre�xo das redes dos endereços IP.

Então, uma tabela de encaminhamento terá, conceitualmente, um conjunto de pares

(P,R) onde �P� é o pre�xo da rede e �R�, é o endereço IP do próximo roteador para onde os

dados devem ser enviados com o objetivo de chegarem a rede �P�.

Pode-se pensar que o protocolo de roteamento, software que preencherá as informações na

FIB, escolherá as melhores rotas de acordo com a utilização corrente do link, pelo tamanho

do datagrama, tipo de dados que estão sendo transportados ou ainda de acordo com o

custo dos links. Entretanto, será visto que a maioria dos protocolos de roteamento são bem

menos so�sticados, selecionando rotas baseadas em dados �xos sobre menores caminhos.

Fato que é interessante ressaltar, já que nas redes de�nidas por software, novos protocolos de

roteamento com as mais diversas métricas poderão ser implementados facilmente, tornando

o encaminhamento mais inteligente e robusto.

Voltando-se ao encaminhamento de pacotes, o algoritmo realizado pelo roteador ao re-

ceber um pacote pode ser resumido na Figura 2.4.

Figura 2.4: Algoritmo executado pelo roteador ao receber um pacote

Fonte: Algoritmo baseado em Comer (2013)

2.4 ROTEAMENTO 11

Entretanto, para o algoritmo acima funcionar corretamente, algumas condições precisam

ser pré-de�nidas.

Primeiramente, diferentemente do modelo conceitual de tabelas de encaminhamento, a

tabela precisa conter o IP da sub-rede de destino que será comparado, a máscara de rede, o

IP do próximo roteador e a interface para onde devem ser enviados os pacotes. A interface

também é importante, pois como um roteador pode estar conectado a duas ou mais redes, o

mesmo precisa saber por qual interface deve enviar os frames. Em segundo, as entradas na

tabela de encaminhamento precisam ser organizadas de forma decrescente, ou seja, as rotas

que apresentarem uma máscara de rede maior (rotas mais especí�cas) devem ser veri�cadas

antes das rotas mais genéricas. Comer (2013)

O encaminhamento, como foi visto, é uma das principais funções do protocolo IP e dos

roteadores. O mesmo não poderia atualmente ser executado corretamente, se não existissem

os protocolos de roteamento. Como será visto a seguir, as entradas na tabela de enca-

minhamento poderiam até ser con�guradas manualmente, mas essa ação com as redes de

computadores atuais, principalmente a Internet, se tornaria impraticável.

2.4 Roteamento

Na seção anterior, foi visto o encaminhamento desempenhado pelo IP, onde dado um

determinado pacote IP, é feita a veri�cação do próximo salto na tabela de encaminhamento

e o direcionamento desse pacote para o mesmo.

As rotas da tabela de encaminhamento podem ser originadas basicamente de três formas.

A primeira são as rotas diretas. São as redes as quais o roteador se conecta diretamente. A

segunda é a forma estática, onde o gestor da rede precisa con�gurar cada rota manualmente.

Pode ser utilizada em pequenas redes domésticas, entretanto em redes mais complexas, onde

existirão diversos roteadores organizados em uma malha, existindo diversos enlaces entre eles,

essa con�guração manual torna-se muito onerosa. A con�guração das rotas manualmente

também torna-se um problema devido à necessidade de reagir dinamicamente às mudanças

da rede, como por exemplo devido à falhas de um enlace ou ainda quando novos roteadores

são acrescentados.

Já na terceira forma, chamada de roteamento dinâmico, as rotas serão con�guradas

automaticamente, de acordo com os protocolos de roteamento e como será visto, existem

basicamente dois tipos predominantes, os protocolos do tipo vetor distância e do tipo estado

de enlace.

Antes de veri�car-se o roteamento dinâmico, torna-se interessante a distinção de pro-

tocolos IGP (Interior Gateway Protocol) e EGP (Exterior Gateway Protocol). A Internet,

como é sabido, é uma rede de redes de computadores. Cada agrupamento organizacional

é de�nido como um sistema autônomo (AS - Autonomous System), sistema esse que pode

operar isoladamente de todos os outros agrupamentos. Logo, nem todas as informações de

2.4 ROTEAMENTO 12

roteamento que são trafegadas internamente dentro de um AS devem ser compartilhadas com

outros AS's, já que não é interessante a divulgação de detalhes internos do mesmo. Com isso,

têm-se os protocolos que distribuem informações de roteamento dentro dos AS's, chamados

de IGP's e os protocolos EGP's, protocolos de roteamento que distribuem informações entre

AS's. Farrel (2004)

A Figura 2.5 ilustra o aprendizado das rotas pelo rotador.

Figura 2.5: Ilustração do aprendizado de rotas pelo roteador e distinção entre as bases de infor-mações de roteamento e de encaminhamento

Fonte: Farrel (2004)

As rotas provenientes a partir dos protocolos de roteamento são combinadas com as rotas

estáticas con�guradas e com as rotas diretas descobertas, dando origem a RIB (Routing

Information Base).

A RIB apresenta diversas informações sobre as rotas disponíveis na rede. Parte dessa

informação pode sugerir várias rotas para um único destino, e um mecanismo de decisão de

roteamento aplica políticas de roteamento para determinar as melhores rotas. A RIB dará

origem a FIB. A FIB oferece informações não ambíguas ao componente do roteador que

encaminha os pacotes de dados.

2.4.1 Protocolos do tipo vetor distância

A ideia dos protocolos dessa modalidade é bastante simples. Cada roteador mantém uma

lista de todos os destinos alcançáveis da rede e distribui essa lista de tempos em tempos

para seus vizinhos.

2.4 ROTEAMENTO 13

Cada entrada na tabela de roteamento identi�cará a rede de destino, o roteador usado

para o próximo salto e a �distância� até a rede de destino. Essa distância geralmente será

a quantidade de saltos (hops) até o destino. Por exemplo, uma rede diretamente conectada

estará a zero saltos de distância. Se um datagrama precisa passar por �N� roteadores para

chegar ao destino, o destino está a �N� saltos de distância.

Quando um roteador novo �X� é inserido, primeiramente ele irá se anunciar aos vizinhos.

Os vizinhos propagarão a informação dizendo que podem chegar até �X� com um salto de

distância e assim sucessivamente.

Quando uma mensagem, por exemplo, proveniente de �X�, chega em �Y�, �Y� tomará as

seguintes ações:

Se �X� conhece um destino que �Y� não, �Y� irá adicionar esse destino a sua tabela de

roteamento, con�gurando como próximo salto �X� e somando 1 ao custo para se chegar a

determinado destino;

Se �X� conhece um caminho mais curto para o destino, �Y� substitui a entrada em sua

tabela de roteamento, con�gurando o próximo salto para �X� e corrigindo o custo;

Se a entrada para um determinado destino já existe em �Y�, sendo o próximo salto para

a mesma, �X� e �X� anuncia um valor de custo diferente ao anterior, �Y� irá atualizar sua

tabela, corrigindo o custo;

Exemplo de tabela de encaminhamento pode ser visto na Figura 2.6.

Figura 2.6: Em (a), tabela de encaminhamento presente no roteador �`Y�. (b) ilustra uma mensa-gem de atualização do roteador �X� que irá causar mudanças em �Y�

Fonte: Imagem baseada em Comer (2013)

Essa modalidade de protocolos, torna-se ideal para redes pequenas a médias, uma vez

que a transmissão de toda a tabela de roteamento para cada vizinho é lenta e a ocorrência de

perdas pode causar loops, demandando um longo tempo para a convergência das informações.

Como vantagens, têm-se a baixa complexidade de implementação e os baixos requisitos de

processamento e memória.

Como exemplos de protocolos do tipo vetor distância, têm-se os protocolos RIP (Routing

Information Protocol) e EIGRP (Enhanced Interior Gateway Routing Protocol).

2.5 ROTEAMENTO 14

2.4.2 Protocolos do tipo estado de enlace

Diferentemente dos protocolos do tipo vetor distância, os protocolos do tipo estado de

enlace não irão distribuir uma lista de rotas, informando os custos e os destinos que o mesmo

pode atingir.

Os roteadores �carão, periodicamente, testando os status das conexões com seus vizi-

nhos, realizando a troca de pequenas mensagens para constatar se o vizinho está ativo e é

atingível. Caso o vizinho responda a mensagem, o link estará up, caso negativo, o mesmo

será considerado down.

Após a descoberta dos vizinhos, o roteador envia periodicamente mensagens para infor-

mar aos outros roteadores da rede sobre os status de cada um de seus links (mensagens

LSP - Link State Packet - ou LSA - Link State Advertisement - de acordo o protocolo). É

importante enfatizar que essas mensagens de status não especi�cam rotas, informam apenas

se a comunicação é possível entre o par de roteadores referidos na mensagem.

Esse processo de inundação das mensagens é simples. O roteador recebe um LSP e veri�ca

em seu banco de dados de estado de enlace se já conhece o enlace referido na mensagem.

Se conhecer, ele descartará o LSP, mas caso não conheça, ele acrescentará o enlace ao seu

banco de dados e enviará o novo LSP em cada uma de suas interfaces, exceto a interface em

que a mensagem foi recebida originalmente.

Logo, após a rede convergir, cada roteador possuirá um mapa completo e idêntico da

rede.

Para calcular as rotas entre os enlaces disponíveis na rede, os roteadores executam o

algoritmo de Dijkstra, algoritmo esse que irá calcular o melhor caminho entre o roteador

local e todos os outros destinos.

Um dos protocolos de estado de enlace mais conhecidos, o OSPF (Open Shortest Path

First), têm uma métrica padrão proporcional à largura de banda dos enlaces. Com isso,

o melhor caminho sempre será o mais rápido, ao contrário do vetor distância, que usa o

caminho com menor número de saltos.

Uma outra vantagem dos protocolos de estado de enlace é que cada roteador realiza

os cálculos das rotas independentemente, usando os mesmos dados de status originais, não

dependendo de roteadores intermediários como o vetor distância. Esse tipo de protocolo

é ideal para redes grandes, pois sua percepção de problemas ou de novos roteadores e a

consequente propagação dessas informações são rápidas. Mas, como desvantagem, o cálculo

das alterações nas tabelas de roteamento exige bastante processamento.

São exemplos de protocolos o OSPF e o IS-IS.

Nessa seção, termina-se uma breve introdução ao funcionamento das redes de compu-

tadores atuais. A próxima seção, tem como objetivo apresentar a comutação baseada em

rótulos, que será a base da tecnologia MPLS. Devido à �exibilidade de roteamento existente

em tal tecnologia, torna-se interessante a citação da mesma, para posterior compreensão das

redes de�nidas por software.

2.5 COMUTAÇÃO BASEADA EM RÓTULOS 15

2.5 Comutação baseada em rótulos

A comutação baseada em rótulos é o processo de encaminhar pacotes de dados dentro

da rede, baseado em algum rótulo associado com cada pacote. Essa ideia surgiu em meados

da década de 1980, com o objetivo de melhorar o desempenho na transmissão de pacotes.

A tecnologia nos comutadores explora o indexamento para atingir velocidades extrema-

mente altas no encaminhamento de dados. Para isso, cada pacote carrega um número inteiro

conhecido como rótulo. Quando um pacote chega no comutador, o comutador extrai o rótulo

e usa o valor como índice na tabela que irá especi�car a ação apropriada. Cada comutador

pode ter uma série de interfaces de saída e a ação geralmente consiste em enviar o pacote

por uma dessas interfaces.

A comutação baseada em rótulos, apresenta como grande vantagem a �exibilidade em

roteamento. Nem sempre é desejável que todos os dados para um mesmo destino sejam rote-

ados pelo mesmo caminho. Pode ser desejado que um tráfego de maior prioridade percorra

um caminho mais curto, enquanto que os tráfegos de menor prioridade, podem ser enviados

por caminhos mais longos. A maioria das técnicas de roteamento como foi visto, costuma

enviar o tráfego para o caminho mais curto.

Como citado, comutação de rótulos consiste em associar um rótulo pequeno e de formato

�xo em cada pacote de dados de modo que ele possa ser encaminhado na rede. Isso signi�ca

que cada pacote, precisa transportar um identi�cador que irá dizer aos nós da rede como

encaminhá-lo. Em cada salto por meio da rede, o pacote é encaminhado com base no valor

do rótulo que chega e é encaminhado com um novo valor de rótulo. A Figura 2.7 ilustra essa

troca de rótulos e o encaminhamento dos pacotes.

Figura 2.7: Troca de rótulos realizada por cada dispositivo

Fonte: Comer (2013)

Até o momento, a comutação baseada em rótulos foi descrita como uma tecnologia de

rede orientada para conexões de propósito geral. Será apresentado agora, como a comuta-

ção baseada em rótulos pode ser combinada com a Internet. Em 1991, a IETF (Internet

Engineering Task Force) padronizou através da RFC 3031 o MPLS.

2.5 COMUTAÇÃO BASEADA EM RÓTULOS 16

O protocolo utiliza a comutação baseada em rótulos, explicada anteriormente e como o

próprio nome sugere, o mesmo foi projetado para transportar quaisquer payloads. Na prática,

o MPLS é usado quase que exclusivamente para transportar pacotes IP.

Geralmente o MPLS é utilizado no núcleo de grandes ISP's (Internet Service Providers).

Roteadores na borda da rede do ISP irão examinar cada datagrama e decidir se utilizará

algum caminho da rede MPLS para encaminhar os dados ou se lidará com o datagrama com

o encaminhamento convencional.

O MPLS permite ao ISP oferecer serviços especiais para clientes individuais. Por exemplo,

considere uma grande empresa com escritórios no Rio de Janeiro e em Porto Alegre. Supondo

que a empresa deseje uma conexão segura entre essas duas localidades com performances

garantidas, o ISP pode estabelecer um caminho na rede MPLS entre esses dois escritórios e

pode con�gurar os roteadores ao longo do caminho para garantir o desempenho contratado.

2.5.1 Classi�cação de pacotes

Como citado anteriormente, o MPLS por utilizar comutação por rótulos, permite uma

maior �exibilidade no roteamento. Isso quer dizer que, em muitos casos, gerentes de redes

usam protocolos da camada de transporte para escolherem quais caminhos determinados

�uxos de dados devem seguir dentro da rede MPLS. Por exemplo, pode existir uma regra

que especi�que que todo tráfego web percorra um determinado caminho diferente dos outros

tráfegos.

Com isso, o modelo de camadas tradicional apresentado na seção �Modelo em camadas� é

insu�ciente para a tarefa de seleção de caminhos na rede MPLS, já que no modelo tradicional

os datagramas em trânsito não são desencapsulados até a camada de transporte.

Logo, se faz necessário de�nir a classi�cação de tráfego. Um sistema de classi�cação difere

do desencapsulamento devido à habilidade de atravessar as camadas.

Para entender a classi�cação de tráfego, imagine um pacote que foi recebido no roteador

e colocado na memória. Pensando no pacote como um array de bytes, para saber se um

determinado pacote corresponde a um tráfego web, basta veri�car alguns bytes. Como por

exemplo, veri�car os bytes correspondentes ao Ethernet type, para saber se é um pacote

IP, veri�car os bytes correspondentes ao campo protocolo, no pacote IP, para saber se o

protocolo utilizado é o TCP e veri�car os bytes correspondentes a porta de destino, para

veri�car se os mesmos correspondem à porta 80. Comer (2013)

Observe que todas as ações representam pesquisas no array de bytes. O sistema de

classi�cação não precisa entender nenhum dos cabeçalhos dos protocolos ou o signi�cado

dos bytes.

Na prática, o mecanismo de classi�cação geralmente utiliza uma série de regras de clas-

si�cação e as aplica até que uma correspondência é encontrada. Por exemplo, um gerente

pode especi�car algumas regras como: enviar todo tráfego web pelo caminho MPLS 1, enviar

todo tráfego RTP pelo caminho MPLS 2 e enviar todo tráfego VPN pelo caminho MPLS 3.

Capítulo 3

SDN - Redes De�nidas por Software

As redes de computadores atuais são compostas de inúmeros dispositivos diferentes como

roteadores, switches e hosts que implementam diversos protocolos complexos. Conforme as

mesmas foram crescendo e se tornando parte essencial da infraestrutura de nossa sociedade,

tornou-se árdua a tarefa de testar e implementar novos protocolos.

Com esse cenário em mente, a ideia de redes programáveis foi proposta com o objetivo

de facilitar futuras evoluções nas redes de computadores. Nesse capítulo, serão apresentados

os conceitos fundamentais das redes de�nidas por software, uma forma de programar a rede

que vem se destacando consideravelmente nos últimos anos.

É um novo paradigma que tem como objetivo facilitar substancialmente a gerência de

redes e permitir inovações e evoluções que o nosso modelo �ossi�cado� atual não permite

Nunes et al. (2014).

3.1 Engenharia de Tráfego

O modelo básico de encaminhamento de pacotes consiste em encaminhar o tráfego com

um dado endereço IP de destino por um caminho pré-estabelecido pelos protocolos de rote-

amento. Independente das outras características dos pacotes, como endereço IP de origem,

portas TCP/UDP ou ToS, todo o tráfego para um determinado endereço IP de destino, ao

chegar em um dado roteador, será encaminhado pela mesma interface.

Isso exposto, surge a necessidade de realizar uma engenharia de tráfego, ou seja, realizar

uma maior distinção entre os diferentes pacotes e, consequentemente, priorizar alguns em

detrimento de outros, com o objetivo de otimizar o desempenho da rede. Hoje, existem

tecnologias que realizam uma distinção e oferecem ao usuário �nal garantias de qualidade

de serviço, como por exemplo, as já citadas redes MPLS. Nas mesmas, através da criação

de circuitos virtuais e da comutação baseada em rótulos, pacotes com um mesmo endereço

IP de destino podem percorrer caminhos diferentes dentro de uma mesma rede.

Como será visto, implementando o paradigma de redes de�nidas por software, haverá um

salto na engenharia de tráfego, já que cada �uxo, ou seja, conjunto de pacotes de dados com

17

3.2 UM NOVO PARADIGMA EM REDES DE COMPUTADORES 18

algumas características em comum, poderá ser tratado individualmente e novos softwares

e formas de encaminhar esses �uxos poderão ser desenvolvidos e implementados de acordo

com as necessidades do gestor da rede.

3.2 Um novo paradigma em redes de computadores

Conceitualmente, um dispositivo de rede, como um roteador ou um switch, pode ser

dividido internamente em dois planos: o plano de controle e o plano de dados.

O plano de controle é a parte responsável pela �inteligência� do dispositivo. Por exemplo,

é o plano de controle que executa os códigos dos protocolos de roteamento, responsável pela

realização do cálculo das rotas em roteadores. Já o plano de dados é responsável por lidar

com os pacotes entrantes no dispositivo, veri�cando na tabela de encaminhamento por qual

interface o mesmo deverá ser encaminhado.

Atualmente, os dispositivos convencionais apresentam uma estreita ligação entre esses

planos. Essa interligação torna árdua a depuração de con�gurações e o controle do compor-

tamento de roteadores e switches Feamster et al. (2014).

A Figura 3.1 ilustra ambos os planos de controle e de dados:

Figura 3.1: Planos de controle e dados.

Fonte: Comer (2013)

O conceito base das redes de�nidas por software consiste em separar o plano de controle

do plano de dados e retirá-lo dos dispositivos. Com isso, a rede será formada por dispositivos

�burros� encaminhadores de pacotes e por uma camada de software programável onde haverá

um controlador de rede que coordenará todas as ações dos dispositivos. Esses dispositivos

encaminhadores de pacotes serão programados através de uma interface aberta, como, por

exemplo, a interface de�nida pelo OpenFlow, que será visto no próximo capítulo.

Atualmente, encontram-se no mercado switches OpenFlow (nomenclatura dada aos dis-

positivos �burros�) tanto puros quanto híbridos. Os puros, não apresentam nenhum plano de


controle, con�ando completamente no controlador para lhe dizer como encaminhar os paco-

tes. Já os híbridos, suportam comandos do controlador em adição às operações e protocolos

atuais Nunes et al. (2014).

A Figura 3.2 ilustra a comunicação do controlador externo com o dispositivo de rede.

Figura 3.2: Con�guração básica SDN, com um controlador externo con�gurando o dispositivo derede.

Fonte: Comer (2013)

Vale salientar que as redes de�nidas por software suportam tanto controladores externos

totalmente centralizados, ou seja, apenas um controlador com visão total da rede, quanto

distribuídos, onde há alguns controladores controlando a rede (mesmo que de forma lógica

aparentem ser apenas um).

Na imagem 3.3, segue uma representação de dispositivos de redes genéricos, com um

sistema operacional externo conhecedor de toda a topologia rodando no controlador e pro-

gramas de controle diversos, sejam novos ou já em uso, como por exemplo, protocolos de

roteamento como OSPF e RIP.

Por ser um novo modelo, existem benefícios e desa�os/desvantagens com a sua imple-

mentação. Seguem abaixo alguns benefícios:

• Visualização uni�cada da rede - Com as redes de�nidas por software, passa-se a ter

uma visão global de toda a rede através do controlador, simpli�cando con�gurações e

gerência dos dispositivos.

• Recuperação mais rápida das falhas - Devido ao controle global, seja a falha em um

link ou em um nó da rede, a rede se reorganizará e convergirá mais rapidamente para


Figura 3.3: Representação de uma rede genérica.

Fonte: McKeown (2011)

uma nova ótima con�guração, devido a utilização de algoritmos centralizados ao invés

de algoritmos distribuídos.

• Upgrade e implementação de novas aplicações - Uma das maiores vantagens desse novo

paradigma é a implementação de novas aplicações para a rede. Novos protocolos e novas

formas de encaminhar os dados poderão ser testadas e implementadas rapidamente,

pois não dependem mais de modi�cações no �rmware do switch ou do roteador. Além

disso, o controlador pode ter seu software atualizado e alterado sem haver perda de

pacotes em uma rede em produção.

Alguns desa�os/desvantagens encontrados são:

• Segurança - Uma das maiores dúvidas e preocupações são a respeito da segurança.

Retirando a �inteligência� dos dispositivos e levando-a para um controlador externo,

passaria-se a ter apenas um ponto crítico, onde caso seja violado, toda a rede sob esse

controlador estaria vulnerável. Essas preocupações se tornam ainda mais evidentes

em empresas que já adotam o conceito de BYOD (Bring Your Own Device) onde os

colaboradores da empresa levam para o ambiente de trabalho seus próprios aparelhos

eletrônicos. Aliando esse conceito com uma rede programável (onde inclusive vírus

poderão ser programados com o objetivo de prejudicar o desempenho e comprometer

a rede), os gestores terão uma preocupação a mais, já que qualquer dispositivo pode

estar contaminado com um software malicioso ao se conectar na rede.

• Conceito novo - As redes de�nidas por software assim como sua implementação mais

difundida, o OpenFlow, ainda se encontram imaturos. Muitos aspectos ainda precisam

ser amadurecidos e novas padronizações realizadas. Como exemplo, qual o nível de


dependência os dispositivos genéricos devem ter dos controladores? Os mesmos devem

ser totalmente dependentes ou apenas parcialmente? Ou ainda, como os controladores

devem ser implementados? Como deve ser realizada a distribuição e separação de

domínios de cada controlador?

Com a retirada do plano de controle dos dispositivos, pode-se modelar e moldar dinâmi-

camente a rede, de acordo com a necessidade do gestor, permitindo que a gerência da rede

seja feita de forma muito mais fácil e e�ciente.

Atualmente, as limitações de largura de banda para cada tipo de serviço são uma re-

alidade, nos permitindo priorizar tráfego VoIP por exemplo, sobre outras aplicações. En-

tretanto, ao longo do dia, as necessidades dos usuários da rede podem ser alteradas e pos-

sivelmente uma determinada aplicação pode vir a ter uma prioridade maior que um tráfego

VoIP.

Com redes de�nidas por software, em tempo real, pode-se haver essa troca de prioridades

e a determinada aplicação prioritária passa rapidamente a trafegar com alta prioridade.

Todo esse modelamento do tráfego poderá ser feito através de um console de gerência, e

em instantes, os dispositivos da rede seriam con�gurados, não havendo mais a necessidade

de conectar-se a cada dispositivo.

Um exemplo similar pode ser visto no webinar da Cisco (Yamamoto e Scharra , 2014),

onde, num primeiro momento, um streaming de vídeo não era executado corretamente devido

a baixa prioridade e saturação do link principal. Após rápidos ajustes no controlador, o link

secundário (redundância) que antes estava ocioso, passou a ser utilizado e o streaming foi

feito corretamente.

Outro exemplo de implementação foi apresentado pelo Google em 2012 na Open Network

Summit (conferência destinada a discussões sobre SDN), onde o mesmo implementou uma

solução OpenFlow/SDN no backbone que trafega os dados entre seus datacenters Google

(2012).

Como visto, as redes de�nidas por software já são uma realidade, mesmo que ainda de

forma tímida. Muito precisa ser evoluído e amadurecido. Questões relativas à segurança

precisam ser devidamente estudadas e analisadas. Mas a liberdade proporcionada por esse

modelo não deixa dúvidas de que num futuro próximo as redes serão muito mais dinâmicas

e programáveis que as atuais, seja utilizando o paradigma SDN ou algum outro que venha

a ser derivado do mesmo.

Capítulo 4

OpenFlow

Após a de�nição do conceito das redes de�nidas por software, vista no capítulo anterior,

algumas dúvidas podem vir a surgir como:

• Como se dará a comunicação entre o controlador e os dispositivos de rede genéricos?

• Quais con�gurações e controle um determinado dispositivo deve oferecer?

• Qual deve ser o formato das mensagens enviadas pelo controlador?

As respostas para tais perguntas podem ser encontradas na implementação mais difun-

dida das redes de�nidas por software, o padrão OpenFlow.

Criado originalmente na universidade de Stanford, o OpenFlow é um padrão aberto,

que surgiu da necessidade dos pesquisadores executarem protocolos experimentais na rede

acadêmica.

É uma tecnologia proposta para padronizar a forma como o controlador se comunica com

os dispositivos de rede em uma arquitetura SDN, de�nindo também um protocolo para essa

comunicação. Dessa forma, o OpenFlow provê meios de controlar os dispositivos de rede

(switches OpenFlow) sem a necessidade dos fabricantes exporem o código de seus produtos.

Lara et al. (2014)

Assim, através do protocolo OpenFlow, os controladores podem programar as tabelas de

�uxo dos switches. Como será visto abaixo, a tabela de �uxos é parte essencial dos switches

OpenFlow.

Diferentes versões do protocolo OpenFlow estão disponíveis. A primeira versão foi a 0.2.0

lançada em Maio de 2008 e atualmente está obsoleta. A versão 1.0.0 lançada em Dezembro

de 2009 foi a mais amplamente divulgada e implementada, com isso a mesma terá um

foco maior nesse trabalho. Após a versão 1.0.0, foram lançadas as versões 1.1, 1.2, e 1.3 e

1.4 Lara et al. (2014).

O OpenFlow encontra-se em constante evolução e o mesmo é mantido pela ONF (Open

Network Foundation).

22

4.1 COMPOSIÇÃO DOS SWITCHES OPENFLOW 23

4.1 Composição dos switches OpenFlow

Baseando-se na versão 1.0.0, a versão mais difundida do OpenFlow, os switches OpenFlow

devem possuir/suportar as seguintes características McKeown et al. (2008):

• Tabela de Fluxos

• Canal Seguro

• Protocolo OpenFlow

A tabela de �uxos contêm 12 campos que serão utilizados para a classi�cação de um

�uxo, uma ação para cada �uxo e contadores.

O canal seguro irá conectar o switch OpenFlow ao controlador e permitirá que os co-

mandos passem por ele.

Já o protocolo OpenFlow é o que será utilizado para essa comunicação.

A Figura 4.1 ilustra as características citadas acima.

Figura 4.1: Switch OpenFlow idealizado.

Fonte: McKeown et al. (2008)

O switch OpenFlow deve ser capaz de realizar três simples ações com os �uxos entrantes:

• Encaminhar o �uxo entrante para uma determinada interface de saída, caso haja uma

entrada equivalente para o �uxo em questão em sua tabela de �uxos;

• Caso não haja entrada equivalente na tabela de �uxos, o switch deve ser capaz de

encapsular o primeiro pacote (ou todos, de acordo com a necessidade) e encaminhá-lo

para o controlador através do canal seguro. O controlador que irá decidir o que fazer

4.2 TABELA DE FLUXOS 24

com esse pacote. Inclusive, decidirá se uma entrada na tabela de �uxos do switch será

adicionada ou não;

• Por último, o switch OpenFlow também deve ser capaz de descartar pacotes;

4.2 Tabela de �uxos

Como dito anteriomente, a tabela de �uxos é parte essencial da caracterização de um

switch OpenFlow. Pode ser observado na Figura 4.2 que uma entrada na tabela de �uxos é

composta por:

Figura 4.2: Entrada da tabela de �uxos.

Fonte: Foundation (2009)

Os campos de cabeçalho são os campos que serão comparados com o �uxo entrante no

switch OpenFlow. A Figura 4.3, apresenta os campos de�nidos na versão 1.0.0:

Figura 4.3: Campos de cabeçalho.


Cada campo do cabeçalho pode ser ou não de�nido. Por exemplo, para o switch OpenFlow

funcionar como um roteador, basta especi�car o campo IP de destino.

Quanto aos contadores existem quatro tipos diferentes: Os contadores por tabela, por

�uxo, por porta e por �la. Os mesmos serão incrementados sempre que �uxos correspondentes

às entradas na tabela entrem no switch e serão utilizados em mensagens de estatísticas,

também de�nidas pelo OpenFlow.

A Figura 4.4 apresenta os contadores disponíveis:


Figura 4.4: Lista dos contadores.


Quanto às ações que deverão ser tomadas com os pacotes, existem ações obrigatórias

que todos os switches OpenFlow devem implementar e outras opcionais. Ao se conectar

ao controlador, o switch deve informar quais ações opcionais o mesmo implementa. Cada

entrada na tabela de �uxos é associada a uma ou mais ações. Se para uma determinada

entrada na tabela não houver uma ação especi�cada, os pacotes desse �uxo serão descartados.

Abaixo seguem os tipos de ações:

• Encaminhamento

� Obrigatório

∗ ALL - Envia o pacote para todas as interfaces, exceto a interface de entrada;

∗ CONTROLLER - Encapsula e envia o pacote para o controlador;

∗ LOCAL - Envia o pacote para a pilha de rede local;

∗ TABLE - Realiza ações na tabela de �uxos;

∗ IN_PORT - Envia o pacote para a porta de entrada;

� Opcional

∗ NORMAL - Processa o pacote utilizando um encaminhamento tradicional;

∗ FLOOD - Inunda o pacote, sem incluir a interface de entrada, levando em

consideração o Spanning Tree.


• En�leirar (opcional) - Encaminha o pacote através de uma �la relacionada a uma

porta;

• Descartar (obrigatória)

• Modi�car campo (opcional)

� Setar Vlan ID

� Setar Vlan Priority

� Separar o cabeçalho da Vlan

� Modi�car endereço MAC (Media Access Control) de origem

� Modi�car endereço MAC de destino

� Modi�car endereço IP de origem

� Modi�car endereço IP de destino

� Modi�car ToS

� Modi�car a porta de transporte de origem

� Modi�car a porta de transporte de destino

A Figura 4.5, apresenta o �uxograma referente a entrada de um pacote em um switch

OpenFlow.

Figura 4.5: Fluxograma do processamento dos pacotes.


Vale salientar que, assim como nos roteadores rotas para sub-redes mais especí�cas têm

prioridade, entradas na tabela de �uxos que especi�quem exatamente o �uxo entrante, ou

seja, entradas na tabela que não apresentem campos coringa, terão sempre a mais alta

prioridade.

4.3 O CANAL SEGURO 27

4.3 O canal seguro

Outra parte essencial da caracterização de um switch OpenFlow é o estabelecimento

de um canal seguro com o controlador. Através desse canal, o controlador irá con�gurar e

gerenciar o switch OpenFlow. De acordo com Comer (2013), embora uma conexão TCP seja

permitida entre o switch e o controlador, o uso de SSL/TLS é recomendado com o objetivo

de garantir con�dencialidade em toda comunicação. É importante lembrar que o OpenFlow

não requer uma conexão física direta entre o switch e o controlador, podendo utilizar redes

já em produção para efetuar a comunicação. Por isso, a importância de um canal seguro.

O protocolo OpenFlow suporta três tipos diferentes de mensagens:

• Controlador-Switch - Geradas pelo controlador para gerenciar e inspecionar o estado

de um switch;

• Assíncronas - Geradas pelo switch para atualizar o controlador sobre eventos da rede

e mudanças no estado do switch;

• Simétricas - Podem ser geradas tanto pelo controlador quanto pelo switch. São enviadas

sem solicitação;

Abaixo, os sub-tipos de cada uma:

• Controlador-Switch

� Características (Features) - O controlador requisita as características do switch.

O switch deve responder com as características suportadas;

� Con�guração (Con�guration) - Usado para con�gurar ou solicitar con�gurações

do switch;

� Modi�cação de estado (Modify-State) - Usado para adicionar, deletar e modi�car

a tabela de �uxos e para setar propriedades nas portas do switch;

� Leitura de estado (Read-State) - Coleta estatísticas;

� Envio de pacote (Send-Packet) - Utilizado para enviar pacotes por uma determi-

nada porta do switch;

� Barreira (Barrier) - Usado para garantir que as dependências foram atendidas

ou para receber noti�cações de operações �nalizadas;

• Assíncrona

� Entrada de pacotes (Packet-In) - Utilizado quando �uxos não classi�cados entram

no switch.

� Remoção de �uxo (Flow-Removed) - Mensagem enviada para o controlador, quando

um �uxo é removido da tabela. Seja por Idle Timeout, Hard Timeout ou por uma

mensagem de modi�cação da tabela de �uxos que delete a entrada em questão;

4.3 O CANAL SEGURO 28

� Estado da porta (Port-Status) - Mensagem enviada para o controlador sempre

que há mudanças nas con�gurações das portas;

� Erro (Error) - Noti�cações de erros;

• Simétrica

� Hello - Mensagens trocadas entre o controlador e o switch quando uma conexão

é estabelecida;

� Echo - Mensagens usadas para identi�cação de latência, largura de banda e exis-

tência de conectividade;

� Vendor - Provêem uma forma padrão para os switches OpenFlow oferecerem

funcionalidades adicionais;

No estabelecimento de uma comunicação OpenFlow, cada um dos lados (controlador e

switch) devem enviar imediatamente uma mensagem Hello (OFPT_HELLO), contendo a

mais alta versão do protocolo OpenFlow suportada pelo dispositivo. Ao receber a mensagem,

o dispositivo deve escolher a menor versão do OpenFlow entre a que foi enviada e recebida.

Se as versões forem compatíveis, a comunicação tem continuidade. Caso não sejam, uma

mensagem de erro é gerada (OFPT_ERROR) e a conexão é encerrada.

É interessante informar também que, caso haja alguma perda de conexão entre o switch

e o controlador, o switch tentará se conectar ao controlador back-up, caso exista. Caso essa

conexão também falhe, o switch entrará em modo de emergência, modo esse que utilizará

apenas as entradas na tabela de �uxos marcadas com um bit de emergência e todas as outras

entradas serão deletadas.

Para modi�car as tabelas de �uxos dos switches, o controlador poderá gerar cinco tipos

de mensagens diferentes. A Figura 4.6 ilustra esses tipos:

Figura 4.6: Tipos de mensagens para modi�cação da tabela de �uxos.


Como pode ser observado, as mensagens ADD adicionarão entradas na tabela de �uxos,

as mensagens do tipo MODIFY modi�carão entradas já existentes e as mensagens do tipo

DELETE apagarão entradas na tabela de �uxo. As mensagens *_STRICT (OFPFC_MODIFY_STRICT

e OFPFC_DELETE_STRICT) buscarão entradas na tabela de �uxos idênticas às especi-

�cadas.

Além das mensagens OFPFC_DELETE e OFPFC_DELETE_STRICT as entradas na

tabela de �uxos podem ser removidos por idle_timeout ou hard_timeout. Caso não entrem

4.4 OUTRAS VERSÕES 29

pacotes correspondentes a uma determinada entrada na tabela em idle_timeout segundos

ou caso transcorra hard_timeout segundos após a inserção da entrada na tabela, a entrada

será apagada.

4.4 Outras versões

Nas seções acima, o OpenFlow 1.0.0 foi apresentado em maiores detalhes, considerando

que o mesmo é a versão mais utilizada e difundida. Entretanto, muitas mudanças foram

realizadas desde o lançamento da versão 1.0.0 até a versão mais atual, a 1.4. Abaixo, seguem

algumas características das versões subsequentes:

4.4.1 OpenFlow 1.1

Na especi�cação do OpenFlow 1.1, os switches OpenFlow contêm diversas tabelas de

�uxos e uma tabela de grupo, ao invés de uma única tabela de �uxos como na versão 1.0.0.

A Imagem 4.7 ilustra os componentes do switch OpenFlow 1.1. Nela podem ser vistas as

diversas tabelas de �uxos, assim como, a tabela de grupo. Ja a Imagem 4.8 ilustra como é

o processamento de pacotes ao entrarem em um switch OpenFlow 1.1.

Figura 4.7: Componentes de um switch OpenFlow 1.1

Fonte: Foundation (2011a)


Figura 4.8: Fluxograma detalhando o �uxo de pacotes através do switch OpenFlow 1.1

Fonte: Foundation (2011a)

Logo, um �uxo de pacotes ao entrar no switch OpenFlow, poderá passar por várias

tabelas de �uxos, para que diversas ações diferentes sejam realizadas.

A tabela de grupo é um tipo especial de tabela projetada para executar ações que sejam

comuns para diversos �uxos.

Além disso, na versão 1.1.0 , três novos campos de cabeçalho foram incluídos: Metadata

(pode ser usada para passar informações entre as tabelas no switch), MPLS label e MPLS

tra�c class.

Maiores detalhes podem ser encontrados na especi�cação OpenFlow 1.1.0 em Foundation

(2011a).

4.4.2 OpenFlow 1.2

O OpenFlow 1.2 foi lançado em dezembro de 2011 e uma das principais implementações

foi o suporte ao protocolo IPv6, incluindo novos campos de cabeçalho nas tabelas de �uxos.

Além disso, o mesmo passou a suportar a possibilidade dos switches se conectarem a mais

de um controlador ao mesmo tempo. Ao se conectar a vários controladores, aumenta-se a

segurança já que o switch pode continuar a operar normalmente mesmo se um controlador

ou a conexão �car indisponível Lara et al. (2014).

Maiores detalhes em Foundation (2011b).


4.4.3 OpenFlow 1.3

Sendo lançada em Junho de 2012, a versão 1.3.0 do OpenFlow passou a suportar o

controle das taxas de pacotes através de medidores de �uxos, introduzindo a tabela de

medições (Meter Table). A tabela de medições por �uxo permite ao OpenFlow implementar

simples operações de QoS, como limitação de taxas de transmissão e pode ser combinada

com as �las por porta para criar políticas de QoS mais complexas. Além disso, a versão

1.3 permite ao switch criar conexões auxiliares para o controlador, ajudando a melhorar o

desempenho de processamento do switch, explorando o paralelismo presente na maioria dos

switches Foundation (2012a).

4.4.4 OpenFlow 1.4

Na versão 1.4 do OpenFlow portas ópticas passaram a ser suportadas. Além disso, os

conceitos de Eviction e Vacancy events foram introduzidos para evitar que as tabelas de

�uxos �quem cheias, já que as mesmas tem capacidades �nitas. Nas especi�cações anteriores

quando uma tabela de �uxos enchia, novos �uxos não eram inseridos nas tabelas e uma

mensagem de erro era enviada para o controlador. Entretanto, atingir tal situação era pro-

blemático e poderia causar interrupções no serviço. O Eviction adiciona um mecanismo que

permite ao switch apagar automaticamente as entradas nas tabelas de �uxos que tenham

menor importância. Já o Vacancy events permite ao controlador con�gurar um limiar, que

ao ser atingido, faz o switch enviar mensagens de alerta para o controlador. Isso permite

que o controlador possa reagir com antecedência, evitando que as tabelas de �uxos �quem

cheias Foundation (2012b).

As subseções acima deram apenas uma visão global sobre as características das ver-

sões do OpenFlow posteriores à 1.0.0. Maiores detalhes e outras características podem ser

encontradas nas especi�cações técnicas, citadas na bibliogra�a.

4.5 POX 32

4.5 POX

Como visto anteriormente, o controlador é parte fundamental nas redes de�nidas por soft-

ware, já que serão os mesmos que irão de�nir a lógica de encaminhamento através das regras

que irão con�gurar nos switches OpenFlow. Atualmente, existem alguns disponíveis para o

uso, como o NOX (Gude et al. , 2008), POX (http://www.noxrepo.org/pox/about pox/ ),

Maestro (Cai et al. , 2010), Trema (http://trema.github.io/trema/ ), Beacon (Erickson ,

2013), entre outros como pode ser visto na Figura 4.9.

Figura 4.9: Alguns controladores OpenFlow existentes

Fonte: Nunes et al. (2014)

O controlador utilizado nesse trabalho foi o POX. O mesmo é derivado do NOX clássico,

um dos primeiros controladores OpenFlow. O POX apresenta como vantagens o fato de ser

implementado em Python, sendo ideal para o ambiente acadêmico. Além disso, o mesmo

apresenta diversos componentes reusáveis e bibliotecas interessantes como as seguintes:

• open�ow.discovery: Utiliza mensagens LLDP (Link Layer Discovery Protocol) para

descobrir a conectividade entre os switches com o objetivo de mapear a topologia da

rede. O mesmo cria eventos (os quais podem ser �escutados�) quando um link �ca up

ou down. Esse componente foi essencial para a aplicação desenvolvida;

• open�ow.spanning_tree: Esse componente utiliza o discovery para contruir uma vi-

são da topologia da rede e constrói uma spanning tree para desabilitar a inundação

(�ooding) nas portas dos switches que não estão na árvore;

• pox.lib.revent: Biblioteca do POX que implementa eventos. Todos eventos do POX são

instâncias de sub-classes da classe Event ;

• pox.lib.recoco: Biblioteca do POX que implementa threads e timers ;

• pox.lib.addresses: Biblioteca utilizada para lidar com endereços IP e Ethernet (MAC);

Capítulo 5

Mininet

O ambiente utilizado para o desenvolvimento da aplicação e realização dos testes foi o

Mininet. Este se trata de um emulador de redes, desenvolvido por pesquisadores da Univer-

sidade de Stanford nos Estados Unidos, com o objetivo de apoiar pesquisas colaborativas

permitindo protótipos autônomos de redes de�nidas por software, para que qualquer pessoa

possa fazer o download, executar, avaliar, explorar e ajustar Lantz et al. (2010).

O Mininet é um emulador do tipo CBE (Container-Based Emulation) que emprega a vir-

tualização a nível de processo, uma forma mais leve de virtualização onde muitos recursos do

sistema são compartilhados. Compartilhando recursos como tabela de paginação, estruturas

de dados do kernel e sistema de arquivos, esse tipo de emulação alcança maior escalabilidade

que outras que realizam uma emulação completa, ou seja, usando uma máquina virtual para

cada dispositivo da rede Heller (2013).

Na Imagem 5.1 é apresentada uma topologia simples que servirá de base para as Imagens

5.2 e 5.3. Nessas duas últimas as diferenças citadas acima, entre CBE e a virtualização

completa, podem ser visualizadas.

Figura 5.1: Topologia simples com dois hosts e um switch.

Fonte: Lantz e O'Connor

33

5.0 34

Figura 5.2: Virtualização completa dos dispositivos.


Figura 5.3: Virtualização "leve"dos dispositivos.


O Mininet é capaz de emular links, hosts, switches e controladores, utilizando processos

que rodem em espaços de nomes da rede (network namespaces) e pares Ethernet virtuais.

• Links: Um par Ethernet virtual atua como um cabo conectando duas interfaces virtuais.

Pacotes enviados através de uma interface são entregues na outra e cada interface se

comporta como uma interface Ethernet completa e funcional para todo o sistema e

aplicação.

• Host: É simplesmente um processo do shell movido para o seu próprio espaço de nome

da rede, ou seja, cada host apresenta uma instância da interface de rede independente.

Cada dispositivo apresenta uma ou mais interfaces virtuais e um pipe para um processo

pai do Mininet (mn), que envia comandos e monitora a saída.

• Switches: Switches OpenFlow são remotamente con�gurados e gerenciados pelo con-

5.0 35

trolador, podendo ser con�gurados para agirem como switches convencionais.

• Controladores: Controladores OpenFlow podem estar em qualquer lugar da rede, ou

seja, tanto na rede física quanto na virtual Lantz et al. (2010).

Para controlar e gerenciar todos os dispositivos emulados, o Mininet fornece uma CLI

(Command Line Interface) conhecedora de toda a rede, ou seja, através de um único console,

pode-se controlar todos os dispositivos emulados. Outra grande vantagem desse emulador

é a facilidade de criação de topologias customizadas através de uma API (Application Pro-

gramming Interface) para programação em Python.

O projeto Mininet nasceu com o objetivo de facilitar os experimentos no campo de

redes de computadores, principalmente para auxiliar nas pesquisas das redes de�nidas por

software e do OpenFlow. Pode ser veri�cado em Heller (2013) uma análise completa do

Mininet, incluindo uma comparação entre os tipos de plataformas para pesquisas em redes

de computadores mais comuns, os simuladores, testbeds e emuladores.

Em Handigol et al. (2012), pode ser veri�cada a robustez do Mininet ao reproduzir

diversos experimentos de redes de computadores escolhidos por estudantes.

O emulador Mininet encontra-se em constante evolução, sendo mantido por uma ativa

comunidade online. O mesmo encontra-se na versão 2.1.0 lançada em Setembro de 2013.

Capítulo 6

A aplicação desenvolvida

Com a tecnologia de redes de computadores atual, torna-se inviável o teste de novos

protocolos em redes que estejam em produção, já que as mesmas foram implementadas com

hardwares especí�cos, que não permitem uma reprogramação.

Conforme visto nos capítulos anteriores, com as redes de�nidas por software, essa li-

mitação já não mais existirá. Equipamentos especí�cos se tornam genéricos e a �gura do

controlador aparece para que possa existir uma rede programável e para que mudanças na

forma de encaminhar os pacotes possam ser realizadas rapidamente.

A aplicação desenvolvida busca mostrar essa facilidade presente nas redes de�nidas por

software.

A mesma foi desenvolvida para alterar o roteamento de um �uxo pré-determinado,

quando o uso da largura de banda do caminho inicial estiver alto. Para tal, foram utili-

zados conceitos do algoritmo de Dijkstra para o cálculo dos caminhos e módulos presentes

no POX, como será visto adiante.

6.1 Executando a aplicação

Ao se inicilizar a aplicação, a primeira ação que é realizada é a descoberta da rede. O

módulo discovery presente no POX faz a descoberta da conectividade entre swicthes Open-

Flow enviando pacotes LLDP. A Imagem 6.1, gerada através de uma captura no Wireshark,

mostra os pacotes LLDP:

Figura 6.1: Pacotes LLDP.

36

6.1 EXECUTANDO A APLICAÇÃO 37

Conforme a descoberta vai sendo feita, um peso é atribuido aos enlaces. Esse peso pode ser

interpretado como o delay do link por exemplo ou qualquer outro parâmetro que signi�que

que quanto maior o valor, pior é o enlace. Para a emulação realizada, se utilizou um gerador

de números aleatórios para a de�nição dos pesos de cada enlace. Após a topologia ser salva,

com a descoberta de todos os switches e a atribuição dos pesos, o algoritmo de Dijkstra é,

então, executado em um codigo complementar.

Esse código complementar (Anexo 10.1), utiliza conceitos do algoritmo de Dijkstra para

realizar o cálculo da melhor e da segunda melhor rotas entre os switches OpenFlow. O código

recebe como parâmetros o nó origem e a topologia e retorna duas listas, uma contendo o

menor custo e a outra contendo o segundo menor custo para se chegar aos outros nós.

A Figura 6.2 apresenta um �uxograma representando essa primeira etapa:

Figura 6.2: Fluxograma representando primeira etapa da execução da aplicação.

Como pode ser visto no �uxograma acima, toda vez que ocorrer um evento de link, ou

seja, quando um link for descoberto ou quando um link �car down, a topologia será alterada

e o código 10.1 será executado.

Ao receber um pacote, o switch enviará uma mensagem de Packet-In para o controlador,

se o switch não possuir entradas em sua tabela de �uxos. A aplicação no controlador tratará

de maneiras diferentes pacotes ARP (Address Resolution Protocol) e os demais. Se o pacote

for um ARP (seja Request ou Reply) o controlador irá gerar um pacote de Packet-Out, ou

seja, o controlador informa ao switch apenas qual deve ser a ação a ser tomada para um

pacote, não havendo modi�cação da tabela de �uxos do switch. A Figura 6.3, mostra os

Packet-In gerados pelos switches, com a resposta Packet-Out do controlador:

Figura 6.3: Pacotes ARP e respota do controlador.


Caso o pacote não seja ARP, o controlador gera uma mensagem de Flow-Mod que irá

inserir uma entrada na tabela de �uxos do switch, como pode ser visto na Figura 6.4.

Figura 6.4: Resposta do controlador para outros pacotes.

Segue na Imagem 6.5, �uxograma dos passos citados acima.

Figura 6.5: Fluxograma representando o evento de Packet-In.

Para cada par de switches origem e destino, a aplicação monitora a taxa de transmissão,

fazendo requisições periódicas de estatísticas do uso da interface. A quantidade de bytes

transmitidos pela porta conectada ao próximo switch (próximo switch de acordo com o

melhor caminho calculado) é salva em uma variável e será comparada com a quantidade da

coleta anterior.

Como na topologia de�nida para o teste (Anexo 9.1) os links foram de�nidos com uma

largura de banda de 100 Mbps, é feito um cálculo com a diferença de bytes transmitidos

em duas coletas e veri�ca-se se a quantidade de bits transmitidos por segundo é menor que

um determinado limiar. Esse limiar foi determinado nos testes como 70 Mbps. Caso seja,

todos os �uxos destinados ao mesmo IP de destino passam pelo melhor caminho. Caso a

quantidade de bits por segundo seja maior que 70 Mpbs, os �uxos que apresentem porta

UDP igual a 2000 são chaveados para a segunda melhor rota.


Figura 6.6: Fluxograma do teste de links e chaveamento entre caminhos.

Como pode ser visto no �uxograma da Figura 6.6, com o objetivo de evitar que �quem

ocorrendo mudanças de rotas a todo momento, foi implementada uma histerese. Assim,

existe um contador que salva o número de ocorrências do evento. Para mudar para o segundo

caminho, o mesmo deve ser maior ou igual a 2 (10 segundos). Para que o �uxo volte para

o melhor caminho, o uso da banda do melhor caminho deve �car abaixo de 70Mbps por

no mínimo o tempo que �cou acima desse limiar. Vale ressaltar que o valor máximo desse

contador é 5 (25 segundos).

O incremento desse contador, assim como outros detalhes menores, não foi indicado no

�uxograma 1.

A aplicação mostra como o controlador pode agir proativamente com o objetivo de evitar

sobrecarga do link e descartes ou até mesmo para a implementação de políticas de QoS de

forma facilitada. Vale ressaltar, que a escolha da porta UDP 2000 foi feita de forma aleatória

e, com facilidade, o código pode ser generalizado para quaisquer portas ou até mesmo para

que altere a rota levando em consideração quaisquer outros campos de cabeçalho de�nidos

em 4.2.

O código completo desenvolvido pode ser analisado no Anexo 11.1.

1Em um primeiro momento, optou-se pela captura da quantidade de pacotes descartados pela interface.Quando o mesmo chegasse a um limiar estabelecido, ocorreria o chaveamento do �uxo para o segundo melhorcaminho. Entretanto mesmo após estressar o link, o contador dos pacotes descartados não foi incrementado.Acreditando ser uma limitação do Mininet, optou-se então pela análise da utilização da largura de banda

Capítulo 7

Simulação e resultados

Para a realização dos testes, foi utilizada uma topologia redundante 1.

Como a proposta dessa monogra�a é apresentar as redes de�nidas por software, mos-

trando a facilidade com que aplicações podem ser desenvolvidas, uma topologia simples foi

escolhida para a realização dos testes.

Nela, foram con�gurados três hosts e cinco switches. Todos os enlaces foram de�nidos

com as mesmas características, com o objetivo de facilitar os testes e a análise dos resultados.

As principais características são:

• bw - Largura de banda de 100Mbps;

• loss - Perda do link de 1%;

• delay - Atraso de 5ms;

• max_queue_size - Tamanho máximo da �la de 10000 pacotes;

A Figura 7.1, ilustra a topologia utilizada.

Primeiramente, o Mininet é inicializado com a topologia personalizada criada e com al-

guns parâmetros extras, para que os endereços MAC �quem de forma mais legível e de�nindo

que o controlador será externo, como pode ser visto na Figura 7.2.

Após a inicialização do emulador Mininet, a aplicação é inicializada. Como pode ser

visto na Figura 7.3 a aplicação é iniciada com os módulos já citados do POX, discovery e

spanning_tree (4.5), já que por padrão o spanning_tree não é ativado.

Para gerar o tráfego para os testes, foi utilizado o Iperf (iperf.fr ). Com o Iperf, é possível

con�gurar um host para atuar como servidor, �escutando� em uma determinada porta e

hosts como clientes, que irão enviar tráfegos para o servidor.

1Descrição da topologia para o Mininet de�nida no Anexo 9.1

40

7.1 METODOLOGIA 41

Figura 7.1: Topologia utilizada nos testes.

Figura 7.2: Inicialização do Mininet.

Figura 7.3: Inicialização da aplicação.

7.1 Metodologia

Na topologia con�gurada, o host 3 foi de�nido como o servidor, e os hosts 1 e 2 como

clientes. Logo, os hosts 1 e 2 gerarão tráfegos para o host 3. De�niu-se que os pacotes enviados

pelo host 1 seriam pacotes UDP com a porta de destino 1000. Já o host 2 envia pacotes

UDP, usando como porta de destino a 2000. Além disso, ambas comunicações tentarão

utilizar 100% da largura de banda e ambos os �uxos são gerados por 180 segundos, ao

mesmo tempo, como pode ser visto nas Figuras 7.4 e 7.5.

Primeiramente, foram realizados os testes com os dois hosts clientes enviando �uxos por

caminhos diferentes, ou seja, o primeiro host enviando pelo melhor caminho e o segundo host

enviando pelo segundo melhor caminho. O objetivo desse procedimento é conhecer os erros

intrínsecos de cada caminho, para que se tenha uma base de comparação para os próximos

procedimentos.

Cada um dos procedimentos foi repetido seis vezes, sendo cada um deles executados após

a inicialização do Mininet e do controlador.

7.1 METODOLOGIA 42

Figura 7.4: Comandos do Iperf nos clientes.

Figura 7.5: Comandos do Iperf no servidor.

A Figura 7.6, apresenta o grá�co do percentual de pacotes perdidos.

O �uxo 1, é o �uxo enviado pelo host 1 e o �uxo 2, é o enviado pelo host 2.

A Figura 7.7 apresenta a resposta do servidor, após o primeiro teste.

7.1 METODOLOGIA 43

Figura 7.6: Percentual da perda de pacotes com os �uxos sendo enviados sempre por caminhosdiferentes.

Figura 7.7: Teste com dois hosts enviando por caminhos diferentes.

Em seguida, foram realizados os testes com ambos os �uxos sendo enviados pelo melhor

caminho. O objetivo é veri�car qual é a porcentagem dos pacotes perdidos, sem utilizar o

chaveamento para o segundo melhor caminho.

O grá�co com o percentual de perda dos pacotes, nos seis testes realizados, é apresentado

na Figura 7.8.

Na Figura 7.9 segue resposta do servidor após o primeiro teste.

7.1 METODOLOGIA 44

Figura 7.8: Percentual da perda de pacotes com ambos os �uxos sendo enviados sempre pelo melhorcaminho.

Figura 7.9: Teste com dois hosts enviando pelo mesmo caminho.

Por �m, realiza-se o teste com o chaveamento dinâmico ativado. A con�guração do ca-

minho alternativo é efetuada caso a utilização da largura de banda �que acima de 70Mbps.

O resultado pode ser visto na Figura 7.10.

A Figura 7.11 apresenta a resposta do servidor após o primeiro teste.

Na Figura 7.12, segue a tabela de �uxos do switch 1, mostrando a modi�cação da interface

de saída para os �uxos que tenham porta UDP igual a 2000.

7.1 METODOLOGIA 45

Figura 7.10: Percentual da perda dos pacotes, realizando a mudança de rota dinamicamente.

Figura 7.11: Resultado do primeiro teste.

Os grá�cos dos percentuais médios de cada procedimento são apresentados na Figura

7.13. Já o grá�co com as taxas médias de transmissão dos �uxos é apresentado na Figura

7.14.

Figura 7.12: Tabela de �uxos do switch 1.

7.1 METODOLOGIA 46

Figura 7.13: Percentual médio dos erros

Figura 7.14: Taxa de transmissão média

Como pode ser veri�cado, o uso da aplicação reduziu consideravelmente as perdas de

pacotes de todos os �uxos, chegando a valores próximos ao experimento dos �uxos sempre

por caminhos diferentes. Para os testes em questão, que foram realizados por um período de

180 segundos, a redução de 1% na perda dos pacotes, equivale a um ganho na recepção de

aproximadamente 8000 pacotes!

Considerando que a redução da perda foi de aproximadamente 5%, �ca bastante clara a

7.1 METODOLOGIA 47

melhoria na entrega dos pacotes.

Capítulo 8

Conclusões

Esse trabalho teve como objetivo introduzir um paradigma diferente da atual implemen-

tação de redes de computadores. Modelo esse que pode vir a ser o predominante em poucos

anos.

Buscando ajudar na compreenssão das redes de�nidas por software, no Capítulo 2, con-

ceitos básicos de redes de computadores foram explanados. Conceitos como modelo em ca-

madas, encaminhamento, roteamento e classi�cação de pacotes, serviram como uma base

para os conceitos seguintes.

O Capítulo 3 de�ne as redes de�nidas por software, modelo que propõe a separação dos

planos de controle e dados, planos esses encontrados nos dispositivos de redes como switches

e roteadores. Com sua separação, é possivel ter um controle total da rede. Já não são mais

necessários hardwares especí�cos, mas hardwares genéricos podem ser utilizados e, através

do controlador, podem ser programados.

O Capítulo 4 apresenta o OpenFlow, implementação mais difundida das redes de�nidas

por software. Um enfoque maior é dado a versão 1.0.0, a versão mais utilizada do OpenFlow.

Entretanto, as diferenças entre as versões mais novas como as versões 1.1, 1.2, 1.3 e 1.4 são

citadas. Nesse capítulo, é apresentado também o POX, controlador implementado em Python

e que foi utilizado nesse trabalho.

No Capítulo 5, o Mininet é apresentado. O mesmo é um emulador de redes desenvolvido

na universidade de Stanford, cuja principal vantagem é o fato de empregar uma forma mais

leve de virtualização, onde muitos recursos do sistema são compartilhados.

Nos Capítulos seguintes, a aplicação é �nalmente descrita e seus resultados mostrados.

Como foi visto, uma topologia simples com cinco switches e três hosts foi utilizada. Fluxos

são gerados por dois hosts clientes para o servidor e de acordo com a utilização da largura

de banda, o caminho de um desses �uxos pode ser alterado.

Como visto, foram realizados três procedimentos. No primeiro, foram realizadas uma série

de testes com o objetivo de descobrir a perda intrínseca dos caminhos. Ao fazer isso, encontra-

se uma base, com a qual poderão ser comparados os resultados dos próximos procedimentos.

No segundo procedimento, testes são realizados com os dois �uxos sendo enviados pelo

48

8.0 49

mesmo caminho. O objetivo é veri�car a quantidade de pacotes que estão sendo perdidos

devido à utilização do mesmo link.

No terceiro procedimento, os testes realizados utilizam a aplicação para realizar o cha-

veamento de um �uxo especí�co (no caso, o �uxo cuja porta UDP de destino seja 2000).

O mesmo passa a utilizar o segundo melhor caminho calculado pelo algoritmo de Dijkstra,

caso a utilização do link principal seja maior ou igual a 70Mbps.

No �nal do capítulo, um grá�co comparativo dos três procedimentos é apresentado. Nele,

percebe-se que a utilização do algoritmo que realiza a troca de rotas dinamicamente reduziu

em torne de 5% a perda de pacotes.

Logo, a prova de conceito foi realizada com sucesso. Os resultados �caram dentro do es-

perado e da proposta inicial. Ainda, o código da aplicação futuramente pode ser modi�cado,

buscando deixá-lo mais genérico ou adequando-o a uma outra situação especí�ca.

Capítulo 9

Apêndice A

9.1 Código para criação da topologia

#Topologia − 5 sw i t ch e s − 3 ho s t s

from mininet . topo import Topo

class MyTopo( Topo ) :

def __init__( s e l f ) :

Topo . __init__( s e l f )

h1 = s e l f . addHost ( ' h1 ' )

h2 = s e l f . addHost ( ' h2 ' )

h3 = s e l f . addHost ( ' h3 ' )

s1 = s e l f . addSwitch ( ' s1 ' )





#Adicionando l i n k s

s e l f . addLink ( h1 , s1 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,

use_htb=True )


use_htb=True )


use_htb=True )

50

9.1 CÓDIGO PARA CRIAÇÃO DA TOPOLOGIA 51

s e l f . addLink ( s1 , s2 , bw=100 , de lay=' 5ms ' , l o s s =1,max_queue_size=10000 ,

use_htb=True )


use_htb=True )


use_htb=True )


use_htb=True )


use_htb=True )


use_htb=True )

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

Código 9.1: Código topologia.py em Python para a criação da topologia, de�nindo a quantidade

de hosts, swicthes e características dos enlaces

Capítulo 10

Apêndice B

10.1 Código para calcular as rotas

# Executa a l gor i tmo de Di jaks t ra , ca l cu lando o melhor e o segundo melhor

caminho ;

def recebe_dados ( no_origem , t opo l og i a ) :

d i s t a n c i a s = {}

distanc ias_segundo = {}

v i z i nho s = {}

vizinhos_segundo = {}

num_nos , nos = calcula_num_nos ( t opo l og i a )

nos_segundo = nos [ : ]

for no in nos :

v i z i nho s [ no ] = [ ]

for i in t opo l og i a :

i f ( no == i [ 0 ] ) :

v i z i nho s [ no ] . append ( [ i [ 2 ] , i [ 1 ] ] )

i f ( no == i [ 2 ] ) :

v i z i nho s [ no ] . append ( [ i [ 0 ] , i [ 1 ] ] )

i f ( no != no_origem ) :

d i s t a n c i a s [ no ] =[−1,−1, 0 ]

for no_segundo in nos_segundo :

viz inhos_segundo [ no_segundo ] = [ ]

for i in t opo l og i a :

i f ( no_segundo == i [ 0 ] ) :

viz inhos_segundo [ no_segundo ] . append ( [ i [ 2 ] , i [ 1 ] ] )

52

10.1 CÓDIGO PARA CALCULAR AS ROTAS 53

i f ( no_segundo == i [ 2 ] ) :

viz inhos_segundo [ no_segundo ] . append ( [ i [ 0 ] , i [ 1 ] ] )

i f ( no_segundo != no_origem ) :

d i s tanc ias_segundo [ no_segundo ] =[−1,−1, 0 ]

for j in v i z i nho s [ no_origem ] :

d i s t a n c i a s [ j [ 0 ] ] = j

d i s t a n c i a s [ j [ 0 ] ] . append (0 )

for l in vizinhos_segundo [ no_origem ] :

d i s tanc ias_segundo [ l [ 0 ] ] = l

d i s tanc ias_segundo [ l [ 0 ] ] . append (0)

v i s i t a d o = 0

while v i s i t a d o == 0 :

peso_minimo = −1no_custo_minimo = None

v i s i t a d o = 1

for j in d i s t a n c i a s :

i f ( d i s t a n c i a s [ j ] [ 2 ] == 0) :

i f ( d i s t a n c i a s [ j ] [ 1 ] != −1) :i f ( ( peso_minimo == −1) or ( peso_minimo > d i s t a n c i a s [ j ] [ 1 ] ) ) :

peso_minimo = d i s t a n c i a s [ j ] [ 1 ]

no_custo_minimo = j

v i s i t a d o = 0

i f v i s i t a d o == 0 :

for v i z inho in v i z i nho s [ no_custo_minimo ] :

i f v i z inho [ 0 ] != no_origem :

i f ( d i s t a n c i a s [ no_custo_minimo ] [ 1 ] + v i z inho [ 1 ] <= d i s t a n c i a s [

v i z inho [ 0 ] ] [ 1 ] ) or ( d i s t a n c i a s [ v i z inho [ 0 ] ] [ 1 ] == −1) :d i s t a n c i a s [ v i z inho [ 0 ] ] [ 0 ] = d i s t a n c i a s [ no_custo_minimo ] [ 0 ]

d i s t a n c i a s [ v i z inho [ 0 ] ] [ 1 ] = d i s t a n c i a s [ no_custo_minimo ] [ 1 ] +

v i z inho [ 1 ]

d i s t a n c i a s [ no_custo_minimo ] [ 2 ] = 1

vis i tado_segundo = 0

while vis i tado_segundo == 0 :


peso_minimo_segundo = −1no_custo_minimo_segundo = None


for j in distanc ias_segundo :

i f ( d i s tanc ias_segundo [ j ] [ 2 ] == 0) :

i f ( d i s tanc ias_segundo [ j ] [ 1 ] != −1) :i f ( ( peso_minimo_segundo == −1) or ( peso_minimo_segundo >

distanc ias_segundo [ j ] [ 1 ] ) ) :

peso_minimo_segundo = distanc ias_segundo [ j ] [ 1 ]

no_custo_minimo_segundo = j


i f vis i tado_segundo == 0 :

for v i z inho in vizinhos_segundo [ no_custo_minimo_segundo ] :

i f v i z inho [ 0 ] != no_origem :

soma_distancias = distanc ias_segundo [ no_custo_minimo_segundo ] [ 1 ]

+ v i z inho [ 1 ]

i f ( ( soma_distancias < distanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] ) or (

d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] == −1) ) :

i f ( ( soma_distancias > d i s t a n c i a s [ v i z inho [ 0 ] ] [ 1 ] or

distanc ias_segundo [ no_custo_minimo_segundo ] [ 0 ] !=

d i s t a n c i a s [ no_custo_minimo_segundo ] [ 0 ] ) ) :

d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] = distanc ias_segundo [

no_custo_minimo_segundo ] [ 0 ]

d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] = soma_distancias

i f ( ( d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] == d i s t a n c i a s [ v i z inho

[ 0 ] ] [ 0 ] ) and ( d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] == d i s t a n c i a s

[ v i z inho [ 0 ] ] [ 1 ] ) ) :

i f ( d i s t a n c i a s [ no_custo_minimo_segundo ] [ 0 ] !=

distanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] ) :

d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] = no_custo_minimo_segundo

distanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] = d i s t a n c i a s [

no_custo_minimo_segundo ] [ 1 ] + v i z inho [ 1 ]

else :

d i s tanc ias_segundo [ v i z inho [ 0 ] ] [ 0 ] = no_custo_minimo_segundo

distanc ias_segundo [ v i z inho [ 0 ] ] [ 1 ] = distanc ias_segundo [

no_custo_minimo_segundo ] [ 1 ] + v i z inho [ 1 ]

d i s tanc ias_segundo [ no_custo_minimo_segundo ] [ 2 ] = 1


#For nece s sa r i o dev ido ao problema quando um no so t inha um unico

v i z i nho e nao era v i s i t a d o para c a l c u l a r o segundo melhor caminhos .

#Try nece s sa r i o po i s como o Djaks tra e chamado antes de toda a t o po l o g i a

e s t a r criada , e l e dava excep t i on . Caso o codigo s e j a chamado apenas

apos a cr iacao de toda a topo l og i a , a excecao nao aparecera mais .

try :

for chaves in vizinhos_segundo . keys ( ) :

i f vizinhos_segundo [ chaves ] [ 0 ] != no_origem :

i f len ( viz inhos_segundo [ chaves ] ) == 1 and distanc ias_segundo [

chaves ] [ 0 ] == −1:d i s tanc ias_segundo [ chaves ] [ 1 ] = distanc ias_segundo [

viz inhos_segundo [ chaves ] [ 0 ] [ 0 ] ] [ 1 ] + vizinhos_segundo [ chaves

] [ 0 ] [ 1 ]

d i s tanc ias_segundo [ chaves ] [ 0 ] = distanc ias_segundo [

viz inhos_segundo [ chaves ] [ 0 ] [ 0 ] ] [ 0 ]

d i s tanc ias_segundo [ chaves ] [ 2 ] = 1

except Exception :

pass

return d i s t an c i a s , d i s tanc ias_segundo

#Calcu la quantos nos ha na t o po l o g i a ;

def calcula_num_nos ( top ) :

Conj_nos = set ( )

for i in top :

Conj_nos . add ( i [ 0 ] )

Conj_nos . add ( i [ 2 ] )

Lista_nos = l i s t (Conj_nos )

Num_nos = len ( Lista_nos )

return Num_nos , Lista_nos

Código 10.1: Código dijkstra.py em Python utilizado para calcular a melhor e a segunda melhor

rotas

Capítulo 11

Apêndice C

11.1 Código da aplicação

from pox . core import core

from pox . l i b . revent import ∗import pox . openf low . l ibopenf low_01 as o f

import pox . openf low . d i s cove ry

import pox . openf low . spanning_tree

from random import randrange

import djakstra_v2

from time import s l e e p

from pox . l i b . addre s s e s import IPAddr

from pox . l i b . r ecoco import Timer

from pox . openf low . of_json import ∗

l og=core . getLogger ( )

class switch_multi ( object ) :

mac_map={}

de lay_l inks={}

def __init__( s e l f ) :

def s ta r tup ( ) :

core . openf low . addLi s t ene r s ( s e l f , p r i o r i t y =0)

core . openf low_discovery . addLi s t ene r s ( s e l f )

#Lis t ene r para eventos e s t a t i s t i c o s

core . openf low . addListenerByName ( "FlowStatsReceived " , s e l f .

handle_flow_stats )

56

11.1 CÓDIGO DA APLICAÇÃO 57

core . openf low . addListenerByName ( "PortStatsRece ived " , s e l f .

handle_ports tats_rece ived )

s e l f . connect i ons = set ( )

core . call_when_ready ( startup , ( ' openf low ' , ' openf low_discovery ' ) )

#Dic ionar io chave − IP ; v a l o r e s − MAC origem e porta do sw i t ch

s e l f .mac_map = {}

s e l f . t opo l og i a = [ ]

s e l f . de lay_l inks = {}

s e l f . por tas = {}

s e l f . dij_1_melhor = [ ]

s e l f . dij_2_melhor = [ ]

s e l f . dij_1_segundo = [ ]

s e l f . dij_2_segundo = [ ]

#Contador que sera u t i l i z a d o para execu tar o Djaks tra . Sem o mesmo , o

a l g o r i t imo de Djaks tra e executado , sem os l i n k s terem s ido

de s cobe r t o s .

s e l f . count = 0

s e l f . l ink_count = 0

s e l f . tx_1 = 0

s e l f . tx_2 = 0

s e l f . d i f e r e n c a = 0

s e l f .LINK_OK = True

s e l f .JA_ENTROU = False

def _handle_LinkEvent ( s e l f , event ) :

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

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

delay_1 = s e l f . de lay_l inks . get ( chave_1 )

delay_2 = s e l f . de lay_l inks . get ( chave_2 )

i f ( delay_1 == None and delay_2 == None) :

de lay = None

chave = chave_1

e l i f delay_1 != None :

de lay = delay_1

chave = chave_1

else :

de lay = delay_2

chave = chave_2

i f event . added == True :


#Dic ionar io das conexoes . Retorna o numero da porta de cada conexao

i f not chave_1 in s e l f . por tas . keys ( ) :

s e l f . por tas . update ({ chave_1 : event . l i n k . port1 })

s e l f . por tas . update ({ chave_2 : event . l i n k . port2 })

i f not ( ( [ event . l i n k . dpid1 , delay , event . l i n k . dpid2 ] in s e l f . t opo l og i a

) or ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] in s e l f . t opo l og i a

) ) :

i f delay == None :

s e l f . de lay_l inks . update ({ chave : randrange (5 , 80 , 5 ) })

s e l f . t opo l og i a . append ( [ event . l i n k . dpid1 , s e l f . de lay_l inks . get ( chave

) , event . l i n k . dpid2 ] )

i f event . removed == True :

i f chave_1 in s e l f . por tas . keys ( ) :

s e l f . por tas . remove ({ chave_1 : event . l i n k . port1 })

s e l f . por tas . remove ({ chave_2 : event . l i n k . port2 })

i f ( [ event . l i n k . dpid1 , delay , event . l i n k . dpid2 ] in s e l f . t opo l og i a ) :

s e l f . t opo l og i a . remove ( [ event . l i n k . dpid1 , delay , event . l i n k . dpid2 ] )

i f ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] in s e l f . t opo l og i a ) :

s e l f . t opo l og i a . remove ( [ event . l i n k . dpid2 , delay , event . l i n k . dpid1 ] )

print ' t opo l og i a −−−− ' , s e l f . t opo l og i a

s e l f . count = s e l f . count + 1

# PARA TOPOLOGIA COM 6 ENLACES, O CONTADOR CHEGA A 12.

i f s e l f . count >= 12 :

s e l f . dij_1_melhor , s e l f . dij_1_segundo = djakstra_v2 . recebe_dados (1 ,

s e l f . t opo l og i a )









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

Timer (5 , s e l f . l ink_tes t , r e cu r r i n g=True )

def _handle_ConnectionUp ( s e l f , event ) :


#pr in t "Entrou ConnectionUP"

#pr in t "CONECTION −−− " , event . connect ion

s e l f . connect i ons . add ( event . connect ion )

def handle_flow_stats ( s e l f , event ) :

f l ow_stats = f low_stat s_to_l i s t ( event . s t a t s )

def handle_ports tats_rece ived ( s e l f , event ) :

segundo_switch = s e l f . dij_1_melhor [ 5 ] [ 0 ]

chave = str ( "1" ) + str ( segundo_switch )

for i in event . s t a t s :

print "CHAVE −−−−−−−" , chave

i f i . port_no == s e l f . por tas . get ( chave ) :

s e l f . tx_1 = i . tx_bytes

i f ( s e l f . tx_2 != 0) :

s e l f . d i f e r e n c a = ( ( s e l f . tx_1 − s e l f . tx_2 ) ∗8) /5

s e l f . tx_2 = i . tx_bytes

s t a t s = f low_stats_to_l i s t ( event . s t a t s )

def _timer_func ( s e l f ) :

print "−−−−−−−− Entrou timer_func −−−−−−−− "

core . openf low . getConnect ion (1 ) . send ( o f . o fp_stats_request ( body=of .

ofp_flow_stats_request ( ) ) )

core . openf low . getConnect ion (1 ) . send ( o f . o fp_stats_request ( body=of .

ofp_port_stats_request ( ) ) )

def l i nk_te s t ( s e l f ) :

#A cada 5 segundos havera v e r i f i c a c a o do l i n k . O s e l f .LINK_OK comeca

como True . Se a d i f e r enca apos 10 segundos f i c a r acima de 70000000

i f ( s e l f . d i f e r e n c a > 0 and s e l f . d i f e r e n c a < 70000000) :

i f s e l f . l ink_count > 0 :

s e l f . l ink_count = s e l f . l ink_count −1else :

s e l f .LINK_OK = True

else :

i f s e l f . l ink_count < 5 :

s e l f . l ink_count = s e l f . l ink_count + 1


i f s e l f . l ink_count >= 2 :

s e l f .LINK_OK = False

i f s e l f .JA_ENTROU == False :

msg = of . ofp_flow_mod ( )

msg . match . dl_type = 0x800

msg . match . nw_proto = 17

msg . match . nw_dst = IPAddr ( " 1 0 . 0 . 0 . 3 " )

msg . match . tp_dst = 2000

msg . id le_timeout = 10

msg . hard_timeout = 60

prox_salto2 = s e l f . dij_1_segundo [ 5 ] [ 0 ]

chave2 = str (1 )+str ( prox_salto2 )

porta_saida2 = s e l f . por tas . get ( chave2 )

msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida2 ) )

core . openf low . getConnect ion (1 ) . send (msg)

def _handle_PacketIn ( s e l f , event ) :

packet = event . parsed

i f packet . type == packet .ARP_TYPE:

IP_ORIGEM = str ( packet . payload . p ro to s r c )

IP_DESTINO = str ( packet . payload . protodst )

else :

IP_ORIGEM = str ( packet . payload . s r c i p )

IP_DESTINO = str ( packet . payload . d s t i p )

PORTA_ORIGEM = None

PORTA_DESTINO = None

i f packet . payload . p ro to co l == packet . payload .TCP_PROTOCOL or packet .

payload . p ro to co l == packet . payload .UDP_PROTOCOL:

PORTA_ORIGEM = packet . payload . payload . s r cpo r t

PORTA_DESTINO = packet . payload . payload . ds tpor t

print "PORTA ORIGEM −−−−−−−" , PORTA_ORIGEM

print "PORTA DESTINO −−−−−−−−−" , PORTA_DESTINO

i f IP_DESTINO == " 1 0 . 0 . 0 . 3 " :


#COMO EM PYTHON NAO EXISTE SWITCH CASE:

i f event . dpid == 1 :

prox_salto = s e l f . dij_1_melhor [ 5 ] [ 0 ]

chave = str (1 )+str ( prox_salto )

porta_saida = s e l f . por tas . get ( chave )

e l i f event . dpid == 2 :












#ARP


msg = of . ofp_packet_out ( )

msg . bu f f e r_id = event . ofp . bu f f e r_id


msg . a c t i on s . append ( o f . ofp_action_output ( port = 1) )

else :

msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida ) )

event . connect ion . send (msg)

else :

i f s e l f .LINK_OK:





msg . match . tp_dst = PORTA_DESTINO




msg . data = event . ofp

msg . buf f e r_id = event . ofp . bu f f e r_id



else :



else :

msg = o f . ofp_flow_mod ( )




msg . match . tp_dst = PORTA_DESTINO







else :

i f PORTA_DESTINO != 2000 :


else :






chave2 = str (2 )+str (5 )









msg . a c t i on s . append ( o f . ofp_action_output ( port = 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 = of . ofp_packet_out ( )

msg . bu f f e r_id = event . ofp . bu f f e r_id



msg . a c t i on s . append ( o f . ofp_action_output ( port = porta ) )

else :



else :

i f s e l f .LINK_OK:



msg . match . nw_dst = IPAddr (IP_DESTINO)







else :



else :

msg = o f . ofp_flow_mod ( )


msg . match . nw_dst = IPAddr (IP_DESTINO)


msg . match . tp_src = PORTA_ORIGEM








else :

i f (PORTA_ORIGEM != 2000) :


else :














msg . a c t i on s . append ( o f . ofp_action_output ( port = porta_saida2 )

)


def launch ( ) :

core . reg i s te rNew ( switch_multi )

Código 11.1: Código app.py em Python, aplicação que realiza a troca dinâmica das rotas

considerando a utilização do link principal

Referências bibliográ�cas

Cai et al. (2010) Zheng Cai, Alan L. Cox e T.S. Eugene Ng. Maestro: A system for scalableopen�ow control. Citado na(s) pág(s).: 32

Central () SDN Central. Documentation. http://www.sdncentral.com/. Último acesso emMaio/2014. Citado na(s) pág(s).:

Comer (2013) Douglas E. Comer. Internetworking with TCP/IP - Principals, Protocolsand Architecture. Pearson, 6 edição. ISBN 9780136085300. Citado na(s) pág(s).: 6, 9, 10, 11,13, 15, 16, 18, 19, 27

Erickson (2013) David Erickson. The beacon open�ow controller. Citado na(s) pág(s).: 32

Farrel (2004) Adrian Farrel. A Internet e seus protocolos. Campus Elsevier, 1 edição.ISBN 9788535266917. Citado na(s) pág(s).: 12

Feamster et al. (2014) Nick Feamster, Jennifer Rexford e Ellen Zegura. The road to sdn:An intellectual history of programmable networks. Citado na(s) pág(s).: 2, 18

Filho (2013) João Eriberto Mota Filho. Análise de tráfego em redes TCP/IP. Novatec, 1edição. ISBN 9788575223758. Citado na(s) pág(s).: 7

Foundation (2009) ONF Open Network Foundation. Open�ow switch speci�cation, ver-sion 1.0.0. Citado na(s) pág(s).: 24, 25, 26, 28

Foundation (2011a) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.1.0. Citado na(s) pág(s).: 29, 30

Foundation (2011b) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.2. Citado na(s) pág(s).: 30

Foundation (2012a) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.3.0. Citado na(s) pág(s).: 31

Foundation (2012b) ONF Open Network Foundation. Open�ow switch speci�cation,version 1.4.0. Citado na(s) pág(s).: 31

Google (2012) Google. Inter-datacenter wan with centralized te using sdn and open�ow,2012. Citado na(s) pág(s).: 21

Gude et al. (2008) Natasha Gude, Ben Pfa�, Teemu Koponen, Martín Casado, ScottShenker, Justin Pettit e Nick McKeown. Nox: Towards an operating system for networks.Citado na(s) pág(s).: 32

66

http://www.sdncentral.com/

11.1 REFERÊNCIAS BIBLIOGRÁFICAS 67

Handigol et al. (2012) Nikhil Handigol, Brandon Heller, Vimalkumar Jeyakumar, BobLantz e Nick McKeown. Reproducible network experiments using container-based emula-tion. Citado na(s) pág(s).: 35

Heller (2013) Brandon Heller. Reproducible Network Research with High-Fidelity Emula-tion. Tese de Doutorado. Citado na(s) pág(s).: 33, 35

http://archive.open�ow.org/wp/learnmore/ () http://archive.open�ow.org/wp/learnmore/.Documentation. http://archive.open�ow.org/wp/learnmore/. Último acesso em Maio de2014. Citado na(s) pág(s).:

https://open�ow.stanford.edu/display/ONL/POX+Wiki ()https://open�ow.stanford.edu/display/ONL/POX+Wiki. Pox wiki. https://open�ow.stanford.edu/display/ONL/POX+Wiki. Último acesso em Novembro de2014. Citado na(s) pág(s).:

http://trema.github.io/trema/ () http://trema.github.io/trema/. Trema. http://trema.github.io/trema/. Último acesso em Novembro de 2014. Citado na(s) pág(s).: 32

http://www.noxrepo.org/pox/about pox/ () http://www.noxrepo.org/pox/aboutpox/. About pox. http://www.noxrepo.org/pox/about-pox/. Último acesso em Novembrode 2014. Citado na(s) pág(s).: 32

iperf.fr () iperf.fr. Documentation. http://iperf.fr/. Último acesso em Maio/2014. Citado

na(s) pág(s).: 40

Kurose e Ross (2010) James F. Kurose e Keith W. Ross. Redes de Computadores e aInternet: Uma abordagem top-down. Pearson, 5 edição. ISBN 9788588639973. Citado na(s)

pág(s).:

Lantz e O'Connor () Bob Lantz e Brian O'Connor. Mininet: An instant virtual networkon your laptop. Citado na(s) pág(s).: 33, 34

Lantz et al. (2010) Bob Lantz, Brandon Heller e Nick McKeown. A network in a laptop:Rapid prototyping for software-de�ned networks. Citado na(s) pág(s).: 33, 35

Lara et al. (2014) Adrian Lara, Anisha Kolasani e Byrav Ramamurthy. Network innovationusing open�ow: A survey. Citado na(s) pág(s).: 22, 30

McKeown (2011) Nick McKeown. How sdn will shape networking, 2011. Citado na(s) pág(s).:

20

McKeown et al. (2008) Nick McKeown, Guru Parulkar, Tom Anderson, Larry Peterson,Scott Shenker, Jonathan Turner, Hari Balakrishnan e Jennifer Rexford. Open�ow: Ena-bling innovation in campus networks. Citado na(s) pág(s).: 2, 23

mininet.org () mininet.org. Documentation. http://mininet.org/. Último acesso em Maiode 2014. Citado na(s) pág(s).:

Nunes et al. (2014) Bruno Astuto A. Nunes, Marc Mendonça, Xuan-Nam Nguyen, KatiaObraczka e Thierry Turletti. A survey of software-de�ned networking: Past, present adfuture of programmable networks. Citado na(s) pág(s).: 17, 19, 32

Opennetworking () Opennetworking. Documentation. https://www.opennetworking.org/. Último acesso em Maio/2014. Citado na(s) pág(s).:

http://archive.openflow.org/wp/learnmore/

https://openflow.stanford.edu/display/ONL/POX+Wiki

https://openflow.stanford.edu/display/ONL/POX+Wiki

http://trema.github.io/trema/

http://trema.github.io/trema/

http://www.noxrepo.org/pox/about-pox/

http://iperf.fr/

http://mininet.org/

https://www.opennetworking.org/

https://www.opennetworking.org/

11.1 REFERÊNCIAS BIBLIOGRÁFICAS 68

Postel (1981) Jon Postel. Rfc 791 - internet protocol, 1981. Citado na(s) pág(s).:

Tanenbaum (2012) Andrew Stuart Tanenbaum. Redes de computadores. Pearson, 5 edição.ISBN 978876059240. Citado na(s) pág(s).:

Wikipédia () Wikipédia. Software-de�ned networking. http://en.wikipedia.org/wiki/Software-de�ned_networking. Último acesso em Maio/2014. Citado na(s) pág(s).:

Yamamoto e Scharra (2014) Kazuo Yamamoto e Marcus Scharra. Fundamentals of sdnin the enterprise - basic concepts and use cases. http://www.cisco.com/web/BR/eventos/quintas_quinze.html, 2014. Último acesso em Novembro de 2014. Citado na(s) pág(s).: 21

http://en.wikipedia.org/wiki/Software-defined_networking

http://en.wikipedia.org/wiki/Software-defined_networking

http://www.cisco.com/web/BR/eventos/quintas_quinze.html

http://www.cisco.com/web/BR/eventos/quintas_quinze.html

desenvolvimento de uma aplicação para diferenciação de caminhos em redes definidas por software

Documents