APLICAÇÃO DO CONCEITO DE SOFTWARE DEFINED NETWORKING EM AMBIENTE VIRTUALIZADO: UMA ABORDAGEM DO SOFTWARE OPENDAYLIGHT UTILIZANDO O PROTOCOLO OPENFLOW

ESCOLA SUPERIOR DE CRICIÚMA – ESUCRI
CURSO DE SISTEMAS DE INFORMAÇÃO
DANILO LUCAS CAMPOS
JEFFERSON FERNANDES MACHADO
APLICAÇÃO DO CONCEITO DE SOFTWARE DEFINED
NETWORKING EM AMBIENTE VIRTUALIZADO: UMA ABORDAGEM
DO SOFTWARE OPENDAYLIGHT UTILIZANDO O PROTOCOLO
OPENFLOW
Criciúma (SC), Novembro/2016

DANILO LUCASCAMPOS
OPENFLOW
Trabalho de Conclusão de Curso apresentado
como requisito parcial para a obtenção do título de
Bacharel em Sistemas de Informação da Escola
Superior de Criciúma, ESUCRI.
Orientador: Prof. Arildo Sônego
Criciúma (SC), Novembro/2016

DANILO LUCAS CAMPOS
OPENFLOW
Trabalho de Conclusão de Curso aprovado pela
Banca Examinadora para obtenção do título de
Bacharel em Sistemas de Informação da Escola
Superior de Criciúma, ESUCRI.
Criciúma, 22 de novembro de 2016.
BANCA EXAMINADORA:
_____________________________________
Prof. Arildo Sônego – Orientador
______________________________________
Profa. Andréia Ana Bernardini
______________________________________
Prof. Cristiano Damiani Tomasi

AGRADECIMENTOS
Primeiramente agradecemos a Deus, que possibilita a tudo e todos momentos
únicos e graciosos, tornando-nos vivos.
Desejamos expressar nossas congratulações a instituição como um todo, ao
ambiente disposto para pesquisas e estudos e principalmente ao corpo docente que
nos forneceram a base conceitual. De suma importância foram os papeis prestados
por nossa coordenadora Andréia Ana Bernardini e professora Muriel de Fátima
Bernhardt. Ao professor orientador Arildo Sônego replicamos o mesmo sentimento,
pessoa da qual consegue expor o conteúdo em paralelo a suas piadas ímpares.
O reconhecimento e apoio recebido por empresas e pessoas físicas foram de
grande gratificação aos acadêmicos, indicando e aconselhando os melhores
caminhos para alcançarmos o objetivo final.
Eu, Danilo Lucas Campos, em especial agradeço a minha mãe Marilza
Lucas, que pode ser como Pai e Mãe ao mesmo tempo, pelo incentivo e por ter
segurado as pontas nos momentos mais difíceis de nossas vidas. É com grande
satisfação que digo que sem o seu apoio nada disso seria possível. Agradeço a toda
a minha família que direta ou indiretamente me ajudaram a alcançar mais este objetivo
na minha vida.
Não poderia deixar de agradecer ao meu colega Jefferson Fernandes
Machado, que eu considero como amigo e me ajudou diversas vezes nas matérias
que não compreendia e pela amizade e confiança.
Eu, Jefferson Fernandes Machado, agradeço e condecoro minha família
como parte fundamental do meu processo acadêmico, pois durante todo o período
tive o apoio e entendimento do quão essa atividade tornou-se importante para atingir
minha realização pessoal e profissional. Em especial a minha mãe, Nair de Oliveira
Fernandes, que durante todos os anos esteve ao meu lado sem somar esforços para
contribuir com quem me tornei. O mesmo a meu Pai, Joacir de Jesus Machado, que,
contudo, alavancou a ideia do que um homem precisa ser e o que eu precisava buscar.
Ao meu colega Danilo Lucas Campos, que ao decorrer dos meses possibilitou
o fortalecimento da amizade e confiança, auxiliando e também se responsabilizando
por tudo o que era proposto. Ficam também as desculpas por momentos de
pertinências ao perfeccionismo e tecnicismo.

SUMÁRIO
LISTA DE FIGURAS ...................................................................................................6
LISTA DE QUADROS .................................................................................................8
ABREVIATURAS.........................................................................................................9
RESUMO...................................................................................................................11
1 INTRODUÇÃO......................................................................................................12
1.1 JUSTIFICATIVA..................................................................................................12
1.2 OBJETIVOS........................................................................................................13
1.2.1 OBJETIVOS GERAL.......................................................................................13
1.2.2 OBJETIVOS ESPECÍFICOS...........................................................................13
1.3 ORGANIZAÇÃO .................................................................................................13
2 REDES DE COMPUTADORES ............................................................................14
2.1 IDENTIFICAÇÃO DAS REDES DE COMPUTADORES .....................................14
2.2 AMPLITUDE DAS REDES..................................................................................15
2.3 ARQUITETURAS................................................................................................16
2.3.1 MODELORM-OSI (REFERENCE MODEL FOROPEN SYSTEMS
INTERCONNCECTIONS) .........................................................................................16
2.3.2 PROTOCOLO TCP/IP (TRANSMISSION CONTROL PROTOCOL/INTERNET
PROTOCOL).............................................................................................................19
2.3.2.1 CAMADA DE APLICAÇÃO...........................................................................20
2.3.2.2 CAMADA DE TRANSPORTE.......................................................................20
2.3.2.3 CAMADA DE INTERNET .............................................................................21
2.3.2.4 CAMADA DE ACESSO À REDE ..................................................................22
2.4 RESUMO DO CAPÍTULO...................................................................................22
3 SDN ......................................................................................................................24
3.1 DEFINIÇÃO ........................................................................................................24
3.2 OPENFLOW .......................................................................................................26
3.2.1 PORTAS OPENFLOW....................................................................................28
3.2.2 TABELAS DE FLUXO OPENFLOW ...............................................................29
3.2.3 CANAL OPENFLOW ......................................................................................31
3.3 CONTROLADORES ...........................................................................................31
4 APRESENTAÇÃO PRÁTICA ................................................................................33

4.1 AMBIENTE FÍSICO.............................................................................................33
4.2 AMBIENTE VIRTUAL..........................................................................................34
4.2.1 SOFTWARES UTILIZADOS...........................................................................34
4.2.1.1 UBUNTU.......................................................................................................34
4.2.1.2 MININET.......................................................................................................34
4.2.1.3 OPENDAYLIGHT..........................................................................................36
4.2.2 PREPARAÇÃO DO AMBIENTE .....................................................................37
4.2.2.1 INICIALIZAÇÃO DO OPENDAYLIGHT ........................................................37
4.2.2.2 CRIAÇÃO DA TOPOLOGIANO MININET ....................................................38
4.2.2.3 UTILIZAÇÃO DO CONTROLADOR .............................................................39
4.3 CASOS DE USO.................................................................................................41
4.3.1 BLOQUEIO DE COMUNICAÇÃO...................................................................41
4.3.2 COMUNICAÇÃO DE REDES DISTINTAS......................................................42
4.3.3 ALTERAR COMUNICAÇÃO DE ENDEREÇO DE IP DO DESTINO ..............44
4.3.4 SWITCH EM MODO REATIVO ......................................................................47
4.3.5 OUTROS CASOS DE USO ............................................................................50
4.4 DIFICULDADES ENCONTRADAS .....................................................................51
5 CONSIDERAÇÕES FINAIS ..................................................................................53
5.1 CONCLUSÕES...................................................................................................53
5.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS.......................................54
REFERÊNCIAS.........................................................................................................55
APÊNDICE A – TOPOLOGIA MININET....................................................................57
APÊNDICE B – ACTIVATOR.CLASS .......................................................................60
APÊNDICE C – PACKETHANDLER.CLASS ............................................................63

LISTA DE FIGURAS
Figura 1: Abrangência de LANs, MANs e WANs.......................................................16
Figura 2: Camadas RM-OSI......................................................................................17
Figura 3: Camadas TCP/IP .......................................................................................20
Figura 4: Arquitetura SDN .........................................................................................26
Figura 5: Principais componentes do switch OpenFlow ............................................27
Figura 6: Fluxo do pacote em um switch OpenFlow..................................................30
Figura 7: Estrutura do Ambiente Físico .....................................................................33
Figura 8: Comando para criar a rede usando o Mininet ............................................35
Figura 9: Terminal de comando do Mininet ...............................................................35
Figura 10: Comando para listar os nós do Mininet....................................................35
Figura 11: Comando para testar conectividade (ping) no Mininet .............................35
Figura 12: Comando de ajuda (help) do Mininet .......................................................36
Figura 13: Logo do OpenDaylight..............................................................................36
Figura 14: Inicialização do controlador OpenDaylight ...............................................37
Figura 15: Tela de autenticação do OpenDaylight via navegador.............................37
Figura 16: Tela inicial do OpenDaylight via terminal .................................................38
Figura 17: Inicialização da topologia virtual no Mininet .............................................38
Figura 18: Execução do comando Pingall no Mininet................................................38
Figura 19: Tela inicial do OpenDaylight via navegador .............................................39
Figura 20: Criação de regras no OpenDaylight .........................................................39
Figura 21: Ações de uma regra no OpenDaylight .....................................................40
Figura 22: Desinstalar regra de fluxo no OpenDaylight.............................................41
Figura 23: Ping entre h1 e h2 no Mininet – Funcionando..........................................41
Figura 24: Adicionar regra para bloquear tráfego entre h1 e h2 no OpenDaylight ....42
Figura 25: Ping entreh1 e h2 no Mininet– Não Funcionando ....................................42
Figura 26: Comunicação entre redes distintas no Mininet não funcional ..................43
Figura 27: Adicionar Gateway IP Address.................................................................43
Figura 28: Adicionar Gateway rede 10.10.0.0/24 no OpenDaylight...........................43
Figura 29: Adicionar Gateway rede 172.16.20.0/24 no OpenDaylight.......................44
Figura 30: Comunicação entre redes distintas no Mininet funcional .........................44
Figura 31: Iniciar Serviço Web ..................................................................................44
Figura 32: Teste de Telnet com H3 no Mininet – Conexão Recusada ......................45

Figura 33: Regra de alteração do destino no OpenDaylight......................................45
Figura 34: Regra de alteração da origem no OpenDaylight ......................................46
Figura 35: Teste de Telnet com H3 no Mininet – Conexão Estabelecida..................47
Figura 36: Identificar ID do pacote de software simple forwarding no OpenDaylight 47
Figura 37: Identificar ID do pacote de software load balancer no OpenDaylight.......47
Figura 38: Parar os serviços de ID 16 e 66 no OpenDaylight ...................................47
Figura 39: Instalar pacote de software no OpenDaylight...........................................48
Figura 40: Iniciar pacote de software no OpenDaylight.............................................48
Figura 41: Iniciar topologia linear com o Mininet .......................................................48
Figura 42: Visualização da topologia linear do caso de uso 4...................................48
Figura 43: Iniciando o XTerm no h1 e h2 no Mininet.................................................49
Figura 44: Abrir conexão na porta 8888 no h2 com o Netcat....................................49
Figura 45: Enviar pacote do h1 para o h2 na porta 8888 com o Netcat ....................49
Figura 46: Notificação da tentativa de tráfego exibida no OpenDaylight...................49
Figura 47: Exibir fluxos do s1 com comandos do Open vSwitch...............................50
Figura 48: Parar pacote de software instalado no OpenDaylight ..............................50
Figura 49: Conexão estabelecida entre h1 e h2 na porta 8888 com o Netcat...........50

LISTA DE QUADROS
Quadro 1: Interação entre camadas..........................................................................19
Quadro 2: Protocolos de camada de rede do TCP/IP. ..............................................22
Quadro 3: Portas reservadas do protocolo OpenFlow ..............................................29
Quadro 4: Exemplos de controladores SDN..............................................................31
Quadro 5: Identificação dos hosts e endereços IP da topologia virtual .....................38
Quadro 6: Descrição de algumas ações possíveis no OpenDaylight........................40

ABREVIATURAS
API – Application Programming Interface
ARP – Address Resolution Protocol
ARPANET– Advanced Research Projects Agency NETwork
ASCII– American Standard Code for Information Interchange
CAM – Content Addressable Memory
DNS – Domain Name System
DSL – Digital Subscriber Line
ESUCRI – Escola Superior de Criciúma
FTP – File Transfer Protocol
ICMP– Internet Control Message Protocol
ID – IDentificação
IGMP– Internet Group Message Protocol
IP – Internet Protocol
ISO – International Organization for Standardization
JAR – Java ARchive
JPEG – Joint Photographic Experts Group
LAG– Link Aggregation Group
LAN – Local Area Network
LTS – Long Term Support
MAC– Media Access Control
MAN – Metropolitan Area Network
ONF –Open Networking Foundation
OSI – Open Systems Interconnections
OVS –Open VSwitch
PPP – Point-to-Point Protocol
QoS – Quality of Services
RARP– Reverse Address Resolution Protocol
REST – REpresentational State Transfer
RJ-45– Registered Jack-45
RM–Reference Model
SCTP– Stream Control Transmission Protocol
SDN – Software Defined Network

SIP– Session Initiation Protocol
SMTP– Simple Mail Transfer Protocol
SNMP – Simple Network Management Protocol
TCP – Transmission Control Protocol
TI – Tecnologia da Informação
TLS– Transport Layer Security
ToS– Type of Service
UDP – User Datagram Protocol
URL –Uniform Resource Locator
VLAN – Virtual Local Area Network
WAN – Wide Area Network

RESUMO
A inovação é um ponto crítico para as empresas, pois traz consigo questionamentos
relacionados as mudanças, se de fato são válidas e funcionais. A arquitetura
emergente do conceito de SDN (Software Defined Networking) implica diretamente no
método de funcionamento das redes convencionais. O conceito busca segmentar o
funcionamento dos equipamentos de rede, deixando aos ativos a responsabilidade de
encaminhar as informações, trabalhando somente com o plano de dados, e assim todo
o plano de controle será tratado através das regras definidas em um centro de
controle. O controlador terá por função aplicar as condições de fluxo aos
equipamentos por ele gerenciados. Essa segmentação de atividades provê ao
administrador de rede um único ambiente para configuração dos equipamentos, sendo
necessário ter expertise somente ao que diz respeito ao controlador definido.
Palavras-chave: SDN, Redes de Computadores, OpenFlow, OpenDaylight.

12
1 INTRODUÇÃO
No presente cenário das organizações, tem se percebido o crescimento e a
competitividade na busca de práticas modernas e seguras na área de TI (Tecnologia
da Informação), sendo uma parte fundamental e estratégica para os negócios. A
internet tornou-se comercial e os equipamentos de redes tornaram-se impossibilitados
às implementações de softwares em hardware proprietário, resultando no
engessamento das arquiteturas de redes.
SDN (Software Defined Networking) representa uma maneira de olhar as
redes de modo a serem controladas por softwares (controladores SDN). Deve-se
observar o que existia antes do mundo SDN. As arquiteturas de rede tradicionais têm
limitações significativas que devem ser superadas para atender às modernas
exigências da tecnologia da informação. A rede atual deve ser dimensionada para
acomodar maiores cargas de trabalho com maior agilidade, além de manter o custo
em um nível mínimo. O conceito de SDN traz muitas ideias em matéria de redes e é
visto como uma grande inovação em TI.
O presente trabalho apresenta com o uso do simulador de redes de
computadores Mininet, a implementação do protocolo OpenFlow, e finalmente é
utilizado o controlador OpenDaylight através de exemplos de uso, com o intuito de
preparar cenários que sirvam como base para a realização da apresentação do
conceito de SDN.
1.1 JUSTIFICATIVA
Redes Definidas por Softwares, comumente conhecidas por SDN,
representam uma tecnologia em crescimento no mercado com amplas vantagens
diretamente relacionadas ao gerenciamento de redes.
O conjunto de ferramentas que compõem uma infraestrutura SDN proverá aos
administradores de rede, um controle centralizado podendo ser moldado de acordo
com a necessidade da empresa. O uso de controladores open source ou pagos, tem
por função replicar as configurações de cada ativo conforme o administrador sinta
necessidade, visto que a camada de controle pode não ficar mais alocada em
equipamentos, como switches e roteadores de rede, uma vez que estes passam a ser
configurados com SDN.
A realização do presente trabalho possui o objetivo de apresentar o conceito

13
de SDN através do controlador open source OpenDaylight em conjunto ao OpenFlow.
1.2 OBJETIVOS
1.2.1 OBJETIVOS GERAL
Apresentar um estudo de Software Defined Network em laboratório
virtualizado utilizando o software OpenDaylight.
1.2.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos deste estudo são:
• Consolidar os conhecimentos relacionados às redes de computadores;
• Investigar as peculiaridades e conceitos inerentes à tecnologia SDN;
• Apresentar uma ferramenta voltada ao controle de redes definidas por software;
• Desenvolver um ambiente na ferramenta escolhida.
1.3 ORGANIZAÇÃO
O presente trabalho de conclusão de curso está organizado em cinco
capítulos. Nesta seção será apresentada a composição dos assuntos abordados da
seguinte forma.
O capítulo dois, proporciona um estudo sobre redes de computadores,
demonstrando a identificação das redes de computadores, suas amplitudes,
arquiteturas e juntamente com os protocolos que envolvem o processo de uma rede
e sua comunicação.
O conceito de SDN será apresentado no capítulo três, no qual são abordados
os principais termos e componentes relacionados ao tema, focando no gerenciamento
da rede através do protocolo OpenFlow, sendo apresentados também aspectos da
infraestrutura e controladores pertinentes ao assunto.
Já no capítulo quatro será exposta a proposta deste Trabalho de Conclusão
de Curso, ressaltando o gerenciamento da rede por meio de um controlador em um
laboratório virtual.
Por fim, no capítulo cinco são apresentadas as considerações finais, sas
conclusões e recomendações para trabalhos futuros.

14
2 REDES DE COMPUTADORES
Este capítulo apresenta a definição de redes de computadores juntamente
com a diversidade e mudanças de hardware com possibilidades de conexão. Em
seguida, explana-se acerca das amplitudes das redes e do modelo de referência OSI
(Open Systems Interconnection). Por fim, será apresentada a arquitetura TCP/IP
(Transmission Control Protocol/Internet Protocol) e suas definições, relacionadas a
redes de computadores.
2.1 IDENTIFICAÇÃO DAS REDES DE COMPUTADORES
Apesar de várias definições ao conceito geral de redes, apresentadas em
diversas referências, pode-se dizer que uma rede é a interligação entre dispositivos
(normalmente chamados de nós), como aparelhos móveis, impressoras,
computadores, entre outros, através de algum meio de comunicação podendo ser com
ou sem fio. Redes de computadores são comumente identificadas quando dispositivos
estão conectados e passíveis de troca de informações (FOROUZAN, 2008).
O uso de redes de computadores em ambientes comerciais é amplamente
difundido. Segundo Tanenbaum e Wetherall (2011) um ótimo exemplo do
funcionamento de redes nesse tipo de localização, é o uso compartilhado de um
dispositivo de impressão, podendo gerar economia financeira e hábil para o adepto.
Sendo as redes de computadores um ambiente que possui características
genéricas, devido a utilização de hardwares programados para não atender somente
uma necessidade, como é o caso de sinais de televisão ou telefonia, Peterson e Davie
(2004) julgam que provavelmente essa seja a principal característica que fez com que
as redes de computadores tivessem uma grande e constante evolução, sendo úteis
em diversas aplicações.
As frequentes mudanças e diversidades de hardware e software que
disponibilizam serviços, como geladeiras, televisores e aparelhos celulares, conforme
Moraes (2010), tornam possível identificar diferentes topologias de rede, das quais
são definidas de acordo com a forma e como os computadores são interligados,
confirmadas por Kurose e Ross (2006) que reforçam a complexidade da internet
pública1 que ainda faz o termo redes de computadores parecer desatualizado.
1Rede de computadores mundial (KUROSE; ROSS, 2006).

15
2.2 AMPLITUDE DAS REDES
As LANs (Local Area Network) são definidas por dois ou mais computadores
interligados em uma área local relativamente pequena, podendo trocar informações
entre si (HAYDEN, 1999).
Ao ato de acessar alguma rede a partir de uma área geográfica centralizada
como um prédio ou campus universitário, conforme Kurose e Ross (2006), sua
navegação costumeiramente está sendo efetuado por intermédio de uma rede LAN.
Hayden (1999) afirma que uma MAN (Metropolitan Area Network) é o conjunto
de LANs. Quando uma empresa necessita de expansão, seja ela para um prédio ao
lado ou até mesmo para outro local, é comum que as redes sejam divididas em redes
menores, mas compartilhando as mesmas informações. De forma geral, conforme
Soares, Lemos e Colcher (1995), as MANs possuem semelhanças com as LANs,
porém com maior abrangência e com maior taxa de transferência.
De acordo com Moraes (2010) as redes WAN (Wide Area Network), cuja
tradução refere-se a redes de longa distância, são interconexões de redes em grandes
regiões geográficas, fazendo com que cidades, estados ou países possam conectar-
se. Esses meios possuem conexões de diferentes equipamentos, protocolos e meios
de comunicação, podendo na maioria dos casos transmitir dados via cabos de cobre,
satélite, micro-ondas ou ainda fibra óptica com o intermédio de roteadores2.
Esses ambientes de conexões de longa distância têm como característica um
grande investimento para atender à necessidade de tráfego, sendo ambientes
costumeiramente custeados, gerenciados e sob domínio de operadoras, tornando
essas conexões, de forma geral, públicas (SOARES; LEMOS; COLCHER, 1995).
A Figura 1 demonstra a abrangência das topologias supracitadas:
2Dispositivos utilizados para encaminhar pacotes aos destinos finais, normalmente trabalhando na
camada de rede, conforme seção 2.3.1 (ODOM, 2008).

16
Figura 1: Abrangência de LANs, MANs e WANs
Fonte: Dos Autores.
2.3 ARQUITETURAS
Nas próximas seções serão expostas as definições de arquitetura de
referência que fazem relação ao tema abordado neste documento.
2.3.1 MODELORM-OSI (REFERENCE MODEL FOROPEN SYSTEMS
INTERCONNCECTIONS)
O modelo de referência RM-OSI foi desenvolvido por membros do comitê
técnico de padronização de sistemas de processamento de informações (TC97) e
aprovado pela ISO (International Organization for Standardization) como padrão
internacional de identificação 7498. O padrão supracitado foi criado para ser utilizado
como base para qualificar e orientar o desenvolvimento de recursos relacionados a
tramitação de informações entre sistemas. Não se deve julgar o RM-OSI como uma
definição de arquitetura de rede, visto que esta busca é através de um conceito
auxiliar, de forma mais especializada e produtiva na interconexão de sistemas
(SOARES; LEMOS; COLCHER, 1995).
Exposto por Peterson e Davie (2004) e Lunardi (2007) o modelo de referência
OSI é composto por sete camadas, das quais cada uma possui sua respectiva
finalidade, conforme descrito nos próximos parágrafos.

17
Segue na Figura 2 um modelo de referência dos níveis do Modelo OSI
demonstrando a interconexão de um ou mais nós na rede.
Figura 2: Camadas RM-OSI
Fonte: Adaptado de PETERSON; DAVIE (2004, p. 19)
A camada física fornece os recursos necessários para ligar ou desligar uma
conexão através de suas propriedades mecânicas, elétricas, e funcionais, que
permitem enviar uma cadeia de bits, mas sem executar nenhuma análise conforme
Soares, Lemos e Colcher (1995), e salientado por Peterson e Davie (2004) que
identificam esses bits como brutos. Dispositivos como hubs LAN, repetidores e a
especificação RJ-45 (Registered Jack-45) são exemplos de itens relacionados a essa
camada (ODOM, 2008).
Na camada de enlace utilizam-se unidades denominadas como frames, sendo
objetivo dessa etapa o encaminhamento íntegro e confiável desses através da
conexão física (MORAES, 2010). Algumas atividades para auxílio no tráfego da
informação são aplicadas nessa camada, que segundo Forouzan (2008) são o
framing, endereçamento, controle de fluxo, controle de erros e controle de acesso ao
meio de transmissão, complementado por Kurose e Ross (2006) ratificando que essas
intervenções afetam a informação transmitida em cada enlace de comunicação, ou
seja, de nó a nó. São exemplos pertencentes a essa camada dispositivos como
switches LAN3e modem DSL (Digital Subscriber Line) e protocolos Ethernet, Frame
3Equipamento com função de encaminhar frames baseado no endereço MAC (Media Access Control)
disponível no cabeçalho Ethernet (ODOM, 2008).

18
Relay, PPP (Point-to-Point Protocol) (ODOM, 2008).
A camada 3 ou também camada de rede, faz uso de unidades chamadas de
pacotes, também identificados como datagramas segundo Kurose e Ross (2006), que
são transmitidos entre os nós, e é papel do nível de rede efetuar a definição das rotas
do pacote para que tenha comunicação entre a origem e o destino (PETERSON;
DAVIE, 2004), concedendo à camada de transporte a independência na definição de
detalhes relacionados a chaveamento e roteamento, como o controle de
congestionamento(SOARES; LEMOS; COLCHER). Odom (2008), considera como os
principais recursos o roteamento, endereçamento lógico e determinação de caminhos,
identificando o protocolo IP (Internet Protocol). Dispositivos roteadores são exemplos
de itens relacionados à camada de rede (ODOM, 2008).
A camada de transporte faz intermédio entre as camadas relacionadas ao
meio físico (física, enlace e rede) e as camadas de aplicações (sessão, apresentação
e aplicação), tendo como principal atividade tratar a comunicação entre processos de
equipamentos distintos (MORAES, 2010), que conforme Kurose e Ross (2006) são
feitas através do uso da comunicação lógica, que não analisa enlaces, roteadores ou
switches que possam estar envolvidos na conexão física dos processos.
De acordo com Forouzan (2008, p. 39) "A camada de sessão é responsável
pelo controle de diálogo e sincronização.", e continua dizendo que a mesma busca
suprir alguns recursos não suportados pelas camadas relacionadas ao meio físico,
mas necessários para alguns processos, como comunicação em half-duplex e full-
duplex e adição de pontos de sincronização, complementado por Peterson e Davie
(2004) a possibilidade de gerenciar o fluxo de áudio e vídeo em uma teleconferência.
A camada apresentação, tem como objetivo interpretar a informação
transmitida, efetuando a tradução baseando-se na sintaxe e semântica (formatos
padrões), que de acordo com Forouzan (2008) e Moraes (2010), pode ser executada
junto a função de criptografia e compressão dos dados, também atribuída ao nível de
apresentação. Entre os formatos padrões, podem-se mencionar textos ASCII
(American Standard Code for Information Interchange) e JPEG (Joint Photographic
Experts Group) como exemplos (ODOM, 2008).
Definida como sétima camada do RM-OSI, a camada de aplicação, de acordo
com Forouzan (2008), possibilita ao usuário uma interface para acesso a rede através
de serviços, exemplificado por Peterson e Davie (2004) e Moraes (2010), através do
uso de correio eletrônico e serviços de transferências de arquivos como o FTP (File

19
Transfer Protocol). Odom (2008) complementa inclusive que processos de
autenticação são feitos por esse nível.
2.3.2 PROTOCOLO TCP/IP (TRANSMISSION CONTROL PROTOCOL/INTERNET
PROTOCOL)
Partindo do princípio histórico, de acordo com Marques (2000) e Moraes
(2010), o padrão TCP/IP surgiu na década de 1970, no auge da guerra fria, apoiado
pelo departamento de defesa dos Estados Unidos. O governo tinha como objetivo criar
uma rede de dados militar através do intitulado projeto ARPANET (Advanced
Research Projects Agency NETwork), para garantir que durante os conflitos não fosse
perdida a comunicação entre as bases. Com isso, envolveram-se diversos
laboratórios e pesquisadores que, pela Universidade de Berkeley, obtiveram como
resultado a implantação do TCP/IP em sistemas operacionais Unix.
Peterson e Davie (2004) comentam inclusive que o RM-OSI foi criado após a
estrutura TCP/IP, porém destacam que tal modelo de referência baseou-se da
experiência anterior para que fosse definido. Os mesmos diferem ambas estruturas
de forma que "Embora o modelo OSI de sete camadas possa, com alguma
imaginação, ser aplicado à Internet, um modelo de quatro camadas normalmente é
utilizado em seu lugar" (PETERSON; DAVIE, 2004, p. 20).
A arquitetura da internet como também é chamada, é descrita por alguns
autores como uma subdivisão de quatro ou cinco camadas, que fazem uso do conceito
de interação entre camadas, resumidamente descrito no Quadro 1.
Quadro 1: Interação entre camadas.
Conceito Descrição
Interação de mesma camada em
computadores diferentes
Os dois computadores usam um protocolo para se
comunicarem com a mesma camada em outro
computador. O protocolo definido por cada camada
usa um cabeçalho que é transmitido entre os
computadores para se comunicar o que cada
computador deseja fazer.
Interação de camada adjacente
no mesmo computador
Em um mesmo computador, uma camada fornece um
serviço para uma camada superior. O software ou
hardware que implementa a camada superior requisita
que a camada inferior seguinte realize a função
necessária.
Fonte: ODOM (2008, p. 19)
O presente documento busca incorporar o conteúdo fundamentando-se em

20
quatro camadas exposto na Figura 3 e descrito nas seções seguintes.
Figura 3: Camadas TCP/IP
Fonte: Dos Autores
2.3.2.1 CAMADA DE APLICAÇÃO
A camada de aplicação auxilia na definição dos serviços necessários aos
softwares executados no computador. Em suma, "[...] a camada de aplicação fornece
uma interface entre os softwares rodando no computador e a própria rede." (ODOM,
2008, p. 17).
É função dessa camada, conforme Comer (2006), interagir com os protocolos
pertencentes à camada de transporte, enviando ou recebendo fluxos contínuos de
bytes ou ainda mensagens individuais de acordo com o formato exigido pela mesma.
Baseando-se o RM-OSI na arquitetura da internet pode-se equivaler a
camada de aplicação como uma combinação da camada de sessão, apresentação e
aplicação do modelo de referência (FOROUZAN, 2008).
Protocolos como FTP, SMTP (Simple Mail Transfer Protocol), DNS (Domain
Name System) e SNMP (Simple Network Management Protocol) fazem parte desse
nível do TCP/IP (FOROUZAN, 2008).
2.3.2.2 CAMADA DE TRANSPORTE
A camada de transporte atribui atividades semelhantes a camada quatro do
RM-OSI, dito por Comer (2006, p. 105) a função de "[...] prover a comunicação de um
programa aplicativo para outro", que destacado por Odom (2008) possuí um vasto
número de protocolos relacionados, o UDP (User Datagram Protocol) e TCP como os
principais protocolos.
O UDP pode ser definido como um protocolo não orientado a conexão. Esse

21
grupo de protocolos envia segmentos4 ao destinatário sem qualquer controle de
entrega, ou seja, de forma independente, bem como com verificação de erros limitada.
O protocolo é mais utilizado ao envio de pequenas mensagens que não se precisa
preocupar muito com o fator entrega, pois o processamento do UDP é menor em
relação aos protocolos orientados a conexão (FOROUZAN, 2008).
Já o TCP é tido como um protocolo orientado a conexão que busca
estabelecer uma conexão virtual entre os sistemas antes de iniciar a transferência de
informações, podendo inclusive efetuar o controle de fluxo e de erros5 entre remetente
e destinatário (FOROUZAN, 2008), que condiz a maior confiabilidade do TCP em
relação ao UDP conforme Kurose e Ross (2006).
Forouzan (2008) expõe a existência do protocolo SCTP (Stream Control
Transmission Protocol), sendo um protocolo criado a partir da combinação das
melhores características do UDP e do TCP, fornecendo melhores condições a
serviços de telefonia SIP (Session Initiation Protocol), por exemplo.
2.3.2.3 CAMADA DE INTERNET
Diante o modelo de redes TCP/IP, a camada de internet, seguindo o conceito
de interação entre camadas descrito no Quadro 1, diante uma requisição, trata de "[...]
enviar um pacote de camada de transporte junto com uma identificação da máquina à
qual o pacote deve ser enviado."(COMER, 2006, p. 105).
A também chamada camada de ligação entre redes (FOROUZAN, 2008), é
encarregada de, ao encaminhar o pacote, incluir os cabeçalhos de transporte e
aplicação já definidos pelas camadas anteriores, juntamente ao cabeçalho de
identificação mencionado por Comer (2006). Essa identificação assume-se sendo as
informações de endereçamento IP do remetente e destinatário. Através de tais dados,
os roteadores serão capazes de definir o caminho a ser percorrido para efetivar a
comunicação, que diante o protocolo IP, define-se roteamento como a atividade de
reencaminhar pacotes de dados (ODOM, 2008).
O protocolo IP mencionado anteriormente, conforme Forouzan (2008) é
utilizado e suportado pela estrutura TCP/IP, fazendo uso de outros quatro protocolos
auxiliares de suporte, descritos no Quadro 2.
4Terminologia para as unidades tratadas na camada de transporte (ODOM, 2008).
5Possibilita a retransmissão de frames que possam ter sido descartados (ODOM, 2008).

22
Quadro 2: Protocolos de camada de rede do TCP/IP.
Protocolo Descrição
IP Serviço do tipo best-effort6, que transporta
datagramas sem acompanhamento de rota e
reordenação ao chegar ao destino.
ARP (Address Resolution Protocol) Associa um endereço lógico (IP Address) a
um endereço físico (MAC Address).
RARP (Reverse Address
Resolution Protocol)
Identifica o endereço lógico a partir do
endereço físico.
ICMP (Internet Control Message
Protocol)
Envia mensagens de consulta e notificações
de erros ao emissor do datagrama.
IGMP (Internet Group Message
Protocol)
Facilita a transmissão simultânea de uma
mensagem a um grupo de destinatários.
Fonte: Adaptado de FOROUZAN (2008, p. 44).
2.3.2.4 CAMADA DE ACESSO À REDE
O nível mais baixo da estrutura TCP/IP, segundo Moraes (2010) corresponde
à camada de enlace do RM-OSI, visto que a estrutura de quatro camadas do TCP/IP
não abrange camada física.
Segundo Odom (2008, p. 21) "[...] esta camada define como conectar
fisicamente um computador host à mídia física através da qual os dados podem ser
transmitidos.". O mesmo autor conclui a definição retomando o conceito de interação
entre camadas, já exposto no Quadro 1, de forma a mostrar que a camada de rede
não tem recursos que possibilitem a entrega dos pacotes em meio à rede física, sendo
essa uma função da camada de acesso à rede.
2.4 RESUMO DO CAPÍTULO
Este capítulo discorre sobre o conceito de redes de computadores,
introduzindo do que se trata esse termo em relação a seu funcionamento e amplitudes
de sua atividade.
Em continuidade, explanam-se os modelos de referência RM-OSI com a breve
descrição de suas sete respectivas camadas, apresentação; aplicação; sessão;
6Em português, melhor esforço possível, "Trata-se de um protocolo sem conexão e não confiável [...]
significa que o IP não dispõe de nenhuma verificação ou correção de erros" (FOROUZAN, 2008, p.44).

23
transporte; rede; enlace; física. Posteriormente explica-se as métricas utilizadas pela
também chamada Arquitetura de Internet, TCP/IP, traçando características de cada
camada que compõe esse modelo funcional com exemplos de protocolos para cada
parte da pilha.
Assim, foi possível identificar em contexto geral o funcionamento de uma rede
de computadores, para que ao decorrer da atividade prática, seja possível ter uma
comunicação linear entre os recursos que farão uso da teoria em foco, SDN.

24
3 SDN
Este capítulo tem por finalidade apresentar um estudo sobre a arquitetura
SDN. Através das definições iniciais que contextualizam o conceito, será possível
identificar suas métricas de funcionamento e a correlação deste com a constante
evolução das redes, expondo também alguns exemplos de softwares controladores.
Será esclarecido ainda, o protocolo OpenFlow como aplicabilidade funcional
da arquitetura, descrevendo os recursos de portas de acesso, tabelas de fluxo e ao
canal de comunicação.
3.1 DEFINIÇÃO
A constante evolução da internet é exposta por Peterson e Davie (2004) que
descrevem o desmembramento dos recursos de rede de forma expressiva,
duplicando-se o uso ano a ano, após 1981. Os tópicos anteriores justificam a
constante evolução das tecnologias de comunicação, porém de acordo com Falsarella
(2012), as redes modernas abrangem um grande número de protocolos que somados
a complexidade atribuída às necessidades de usuários e empresas, resultam para os
administradores de rede na execução de atividades dificultosas quando se faz
necessária alguma mudança de rede, como por exemplo, inclusão de novos ativos na
respectiva infraestrutura.
Um dos principais fatores que justificam esse cenário ainda é esclarecido pelo
autor, mencionando a dependência por códigos e protocolos fechados, onde os
equipamentos comercializados possuem suas próprias funcionalidades e
compatibilidades, em certas situações podem gerar tratativas isoladas e com solução
lenta. A partir do pressuposto, entende-se que deve ter sido o motivo para dizeres de
que as redes atuais estão engessadas/limitadas.
Conforme Open Networking Foundation, Onf (2012), a indústria passou a
analisar o funcionamento da arquitetura tradicional considerando atividades triviais em
função dos tempos modernos, como a utilização de dispositivos móveis, servidores
de virtualização e a difusão dos serviços em nuvem (cloud services), determinando
que ambientes como data centers, devido ao funcionamento dinâmico de
armazenamento e processamento, tornam necessários novos princípios para as
redes, com maior flexibilidade em relação a tráfegos padrões, garantia de segurança
no acesso às redes corporativas, e que satisfaçam as requisições dos serviços em

25
nuvem de forma ágil, bem como suportar a alta demanda de tráfego de rede em
ambientes de big data.
Baseando-se inicialmente nesses pontos, foi fundada em 2011 a ONF (Open
Networking Foundation), uma organização sem fins lucrativos dedicada ao
desenvolvimento da abordagem SDN (ONF, 2013).
O presente estudo não se refere a essa data como sendo a idealização de
SDN, somente como período em que uma organização adotou a tendência.
Esse novo paradigma denominado SDN, também dito como redes definidas
por software, de acordo com Onf (2012), é uma arquitetura emergente que possibilita
fornecer um ambiente mais flexível e programável, separando o plano de controle do
plano de dados.
Baseando-se nessa dinâmica de funcionamento, os ativos de rede como
switches e roteadores podem não assumir mais o controle da rede, que é justificado
e complementado por Kim e Feamster (2013 apud REDES, 2014, p. 244) ao dizer que
"Em SDN, dispositivos de rede se tornam apenas dispositivos de roteamento de
pacotes (Plano de dados), enquanto o 'cérebro' ou a lógica de controle é
implementada no Controlador (Plano de Controle)".
Segundo Onf (2012), a SDN também possuí outras duas características
principais. O controle centralizado é uma delas, que possibilita aos mantenedores da
infraestrutura aplicar ajustes ou inserções de novas regras de rede em somente um
centro de inteligência, sendo esse o controlador já mencionado por Kim e Feamster
(2013 apud REDES, 2014), fornecendo uma visão global do ambiente e evitando a
configuração manual, além da independência de arquitetura ou protocolos
proprietários de cada um dos ativos.
A programabilidade é outro diferencial das redes definidas por software, que
fornece aos operadores/administradores de redes um controle centralizado com
disponibilidade de código fonte, sendo possível criar programas que, quando
implantados, propiciam de forma dinâmica e automática a configuração,
gerenciamento e otimização da rede (ONF, 2012).
Essa característica chave ainda permite a implementação de APIs
(Application Programming Interface) com funções de roteamento, multicast, controle
de acesso, QoS (Quality of Services), otimização de processamento e
armazenamento, consumo de energia, entre outras funcionalidades de gerenciamento
ajustáveis às necessidades da empresa (ONF, 2012).

26
As características da arquitetura SDN descritas anteriormente podem ser
visualizadas através da Figura 4, que exibe a divisão entre os planos e as aplicações
agregadas à inteligência da rede.
Figura 4: Arquitetura SDN
Fonte: Adaptado de ONF(2012, p. 7).
Compreendido de Falsarella (2012), SDN é a arquitetura passível de
implantação, fornecendo um modelo de funcionamento de uma infraestrutura de rede,
mas que precisa de um protocolo que atue com base em seus princípios, que
mencionado pelo autor, utiliza-se o OpenFlow, o qual será abordado seções a seguir.
3.2 OPENFLOW
Em fato histórico, porém atualmente apoiado pela Open Networking
Foundation (ONF, 2012), o protocolo OpenFlow teve seu desenvolvimento iniciado em
2007 pelas universidades de Stanford e Berkeley da Califórnia. Este é diretamente
agregado à arquitetura SDN, sendo um protocolo base para que as redes
programáveis sejam abertas e padronizadas (LOBATO; FIGUEIREDO; ALVES, 2013).
Os mencionados autores introduzem o conceito do OpenFlow como um
protocolo que "[...] permite a manipulação e o acesso direto do plano de
encaminhamento dos pacotes de dispositivos de rede, como switches e roteadores,
tanto virtuais como físicos." (LOBATO; FIGUEIREDO; ALVES, 2013, p. 3).
O método de encaminhamento do protocolo torna-o um padrão único e distinto
de outros, visto que permite mover o controle dos comutadores para centros lógicos
(controladores), através de instruções básicas especificadas pelo OpenFlow que

27
podem ser utilizadas por aplicativos externos para programar o controle de fluxo dos
dispositivos de rede, semelhante a atividade de uma unidade de processamento para
com o computador (ONF, 2012).
De acordo com Onf (2012), o protocolo OpenFlow deve ser compatível e
implantado no controlador SDN e no dispositivo de rede a ser gerenciado.
Ao fato de que o controlador SDN provê um serviço centralizado, segundo Onf
(2012), o conceito de fluxo do OpenFlow busca identificar o tráfego e coordena-lo
através de parâmetros estáticos ou dinâmicos programados previamente no centro
lógico, possibilitando uma granularidade de controle por fluxo, implicando respostas
em tempo real em níveis de aplicação, usuário e de sessão.
Em conformidade com Onf (2014), presume-se conceitos de especificação
técnica relacionados ao protocolo OpenFlow em sua versão 1.3.4, sendo a última
atualização de acordo com a data de publicação do presente documento.
O protocolo, em aplicabilidade a switches, tem seu funcionamento ilustrado
conforme a Figura 5, sendo descrito nas seções seguintes.
Figura 5: Principais componentes do switch OpenFlow
Fonte: Adaptado de ONF (2014, p. 8)
De acordo com Onf (2014), pode-se utilizar switches somente com OpenFlow
ou switches híbridos, que executam as regras aplicadas pelo protocolo e, em algumas
situações, podem utilizar seu funcionamento normal, com métodos de funcionamento
nativos como LAG (Link Aggregation Groups), tunnels e interfaces loopback.
Switches OpenFlow compreendem seu funcionamento em tabelas de fluxo
(flow table) e em grupos de tabelas (group table), que possibilitam ações de inclusão,
alteração ou remoção de campos de pacotes entrantes, através de uma comunicação
com o controlador, interligados via um canal OpenFlow (ONF, 2014).
Os switches podem ter a inserção de regras de fluxo através de dois modos

28
de acesso, sendo eles o modo reativo e proativo. O modo com que as regras são
analisadas é esclarecido ao decorrer da seção 3.2.2.
No modo reativo, sempre que for gerado um tráfego no switch e não existir
nenhuma regra já instalada que tenha critérios compatíveis com o pacote
encaminhado, o ativo faz uma requisição ao controlador para verificar se existe
alguma outra regra que possa ser instalada, e que faça referência ao tráfego em
andamento. Com essa metodologia, o controlador pode ser antecipadamente
programado para que tenha inteligência sob o tráfego, porém as regras são instaladas
nos ativos somente quando algum tráfego referente aqueles critérios sejam
identificados (REINA, 2015).
Já no modo proativo, o switch trabalha somente com as regras diretamente
disponibilizadas para ele. A manipulação das métricas de fluxo são feitas através de
funcionalidades fora do código fonte do controlador, e no momento em que uma nova
regra é criada, a mesma já é replicada ao switch. Caso a regra não exista em sua
tabela de fluxo, não será questionado ao controlador a existência de outra métrica
(REINA, 2015).
As seções seguintes têm por objetivo descrever recursos relacionados ao
funcionamento de um switch OpenFlow.
3.2.1 PORTAS OPENFLOW
Conforme especificação do protocolo estabelecida por Onf (2014), switches
OpenFlow são interligados de forma lógica através de portas OpenFlow, logo essas
portas não se referem ao número de portas físicas do equipamento.
Conforme o autor, o equipamento remetente envia uma informação através
de uma porta de saída (output port) e o destinatário recebe através de uma porta de
entrada (ingress port), que são processadas pelo pipeline OpenFlow para então
decidir a ação de saída do pacote.
Segundo Onf (2014), as portas OpenFlow podem ser divididas em três tipos,
sendo as portas físicas, lógicas e reservadas.
As portas físicas correspondem às portas de conexão agregadas ao switch,
seja ele físico ou virtualizado, por exemplo, conexão ethernet. Divergente desse tipo,
as portas lógicas abrangem métodos não necessariamente OpenFlow, que não são
diretamente relacionados ao hardware, mas que possibilitam ao protocolo incrementar
um campo extra chamado Tunnel-ID ao pipeline, podendo o controlador ao receber o

29
pacote, identificar a porta física e a porta lógica do remetente (ONF, 2014).
Com características relacionadas ao protocolo, as portas reservadas são
utilizadas para especificar ações de forwarding (encaminhamento) para controlador,
flooding (inundação) ou através de métodos nativos do switch (não OpenFlow) (ONF,
2014). O Quadro 3descreve brevemente algumas das portas reservadas.
Quadro 3: Portas reservadas do protocolo OpenFlow
Porta Descrição
ALL Representa todas as portas do switch podendo ser utilizada para
encaminhar um pacote específico.
CONTROLLER Representa o canal de controle com o controlador OpenFlow.
TABLE Representa o início de um pipeline OpenFlow.
IN_PORT Representa o pacote da porta de entrada (ingress port).
ANY Valor especial utilizado em requisições OpenFlow sem porta
especificada.
LOCAL Representa os recursos de rede e gerenciamento local do switch.
NORMAL Representa o encaminhamento de modo tradicional (não
OpenFlow).
FLOOD Representa o recurso de inundamento (flooding) do switch de
modo tradicional (não OpenFlow).
Fonte: Adaptado de ONF (2014, p. 13-14).
3.2.2 TABELAS DE FLUXO OPENFLOW
Descrito por Onf (2014), o pipeline OpenFlow é uma abstração do hardware
real do switch, que conforme descrito na Figura 5, engloba as funcionalidades de
grupo de tabelas, tabelas de fluxo e o canal OpenFlow.
As tabelas de fluxo que compõem o pipeline OpenFlow possuem vários fluxos
de entrada, sendo sua responsabilidade definir como os pacotes serão tratados,
podendo interagir com as demais tabelas de fluxo (ONF, 2014).
Cada tabela possuí alguns componentes principais agregados ao fluxo de
entrada, sendo eles identificados como match fields, priority, counters, instructions,
timeouts, cookie e flags7 (ONF, 2014).
Conforme o mesmo autor, concebe-se que as tabelas de fluxo são compostas
de parâmetros que podem ser análogos a colunas, das quais um fluxo de entrada
7Informações detalhadas sobre os componentes de tabela de fluxos em Onf (2014).

30
pode conter um valor especificado, provendo ao switch OpenFlow aplicar regras
diante o pacote, podendo definir a singularidade da regra através das informações
inclusas nos match fields e nas prioridades (Priority).
Onf (2014) complementa esse funcionamento salientando que a tabela define
ações aplicadas à linha de fluxo enquanto no pipeline OpenFlow, podendo por
exemplo, reescrever algum cabeçalho ou encaminhar para outra tabela de fluxo.
A performance dos match fields é identificada no decorrer do processo do
pipeline. Através desse parâmetro é possível identificar, por exemplo, os endereços
MAC e IP do remetente/destinatário, sendo empregado para verificar se o fluxo de
entrada corresponde a regra da tabela de fluxo, iniciando a análise das regras a partir
da primeira tabela. Essa atividade é denominada matching e busca aplicar ações que
encerram o encaminhamento do pacote ou definem o próximo fluxo, podendo ser
outra tabela do pipeline (ONF, 2014).
Diante situações em que o pacote não corresponde a regras, o mesmo autor
esclarece a utilização de uma tabela de fluxo para pacotes perdidos (table-miss flow),
onde é possível descartar o pacote, encaminhar a uma tabela subsequente ou ao
controlador. A Figura 6 ilustra o fluxo de um pacote baseando-se na atividade
matching.
Figura 6: Fluxo do pacote em um switch OpenFlow
Fonte: Adaptado de ONF (2014, p. 18)
De acordo com o número de vezes em que uma tabela recebe um fluxo de

31
entrada, pode-se fazer o uso de contadores, que possibilitam através de números
identificar quantidades de colisões, erros de transmissão, pacotes recebidos, tempo
de duração, entre outros, que podem ser utilizados inclusive para implementar maior
dinâmica ao software de rede (ONF, 2014).
3.2.3 CANAL OPENFLOW
O canal OpenFlow provê a conexão entre o controlador OpenFlow e o switch
OpenFlow, possibilitando a gerência e configuração do ativo, recebimento de eventos
e envio de pacotes ao switch (ONF, 2014).
Segundo Onf (2014), a conexão entre os dispositivos é efetuada através de
um canal encriptado com uso de TLS (Transport Layer Security) sob o protocolo TCP,
interligando um switch a múltiplos controladores, e vice-versa.
A conversação entre os recursos pode ser definida de três formas, controlador
para switch (controller-to-switch), assíncrona e simétrica. O primeiro tipo descreve que
essas mensagens são emitidas pelo controlador e destinadas ao switch para que seja
possível inspecioná-lo e gerencia-lo. Já no método assíncrono são mensagens
encaminhadas pelo switch para notificar mudanças e eventos ao controlador. No
entanto, a troca de mensagens de forma simétrica, permite o envio de informação
entre ambos, mas sem solicitação prévia (ONF, 2014).
3.3 CONTROLADORES
Conforme mencionado diante a arquitetura SDN, faz-se o uso de um software
controlador para administrar a rede. O Quadro 4 expõe algumas aplicações passíveis
de serem utilizadas para um controle centralizado.
Quadro 4: Exemplos de controladores SDN
Controlador Implementação Software Livre Desenvolvedor
POX Python Sim Nieira
NOX Python/C++ Sim Nieira
MUL C Sim Kulcloud
Maestro Java Sim Rice University
Trema Ruby/C Sim NEC
Beacon Java Sim Stanford
Jaxon Java Sim Independent Develpopers
Helios C Não NEC

32
Floodlight Java Sim BigSwitch
SNAC C++ Não Nieira
Ryu Python Sim NTT, OSRG group
NodeFlow JavaScript Sim Independent Develpopers
Ovs-controller C Sim Independent Develpopers
Flowvisor C Sim Stanford/Nieira
RouteFlow C++ Sim CPqD
Fonte: NUNES (2014 apud KLEIS, 2015, p.4).
Este capítulo apresentou a descrição do conceito de redes definidas por
software, esclarecendo o objetivo desse modelo de arquitetura, bem como seus
objetivos e paradigmas.
O contexto de SDN foi esclarecido de forma técnica na abordagem dos tópicos
posteriores à definição, possibilitando explorar o protocolo OpenFlow através de sua
teoria e níveis de funcionamento, detalhando o que é e como funcionam as portas
OpenFlow, tabelas de fluxo e o canal OpenFlow. O centro das redes programáveis é
brevemente demonstrado no tópico de controladores, onde baseando-se no contexto
do capítulo foi possível identificar a diversidade de plataformas passíveis de serem
incorporadas em um ambiente SDN.
O conteúdo exposto possibilitará ao capítulo prático um embasamento teórico
em relação a teoria de SDN para implementação do ambiente virtualizado de forma
funcional.

33
4 APRESENTAÇÃO PRÁTICA
Neste capítulo serão abordados alguns softwares utilizados para a elaboração
de um laboratório virtual para o presente contexto de gerenciamento de redes por
meio do conceito de SDN. O primeiro passo para a realização deste trabalho
compreendeu a identificação de ferramentas que pudessem atender os objetivos
deste trabalho.
4.1 AMBIENTE FÍSICO
Entende-se como infraestrutura física, por exemplo, as instalações dos
equipamentos em um rack, a conexão dos equipamentos à energia elétrica e o
cabeamento estruturado. Na Figura 7 analisa-se a estrutura de uma rede física
utilizando o conceito de SDN, contendo quatro hosts e um controlador conectados a
dois switches. Os switches devem ter definido qual será o controlador do mesmo via
IP Address, criando a conexão lógica entre eles. As funções destes dispositivos seriam
tratadas de modo que o switch ao receber um pacote, passa a tomar a decisão
baseando-se nas regras impostas na respectiva tabela de fluxo, seguindo a atividade
de matching ilustrada na Figura 6, e podendo enviar o pacote para o controlador, caso
esteja funcionando em modo reativo. Essas políticas, então, criam a inteligência da
rede, que o controlador passa a impor no conjunto da topologia, configurando os
switches e consequentemente afetando as máquinas.
Figura 7: Estrutura do Ambiente Físico
Fonte: Dos Autores.

34
Contudo, a implantação de um ambiente físico de tal porte, implica em custos
financeiros não contemplados no presente trabalho. Para lidar com essa condição
optou-se ao uso de um ambiente virtualizado, de modo a aplicar o conceito inerente a
SDN.
4.2 AMBIENTE VIRTUAL
Para a elaboração do ambiente virtualizado se faz necessário o uso de
algumas ferramentas (softwares). Todas as ferramentas apresentadas a seguir são
adquiridas sem custo (open source) e serão explanadas nas seções posteriores.
• Ubuntu – O sistema operacional Ubuntu é demonstrado como base para o
desenvolvimento do presente trabalho, visando o a
• cesso fácil e instalação das próximas ferramentas a serem apresentadas para a
execução deste ambiente e pela experiência dos membros da equipe. Versão
utilizada 16.04 LTS (Long Term Support) (Xenial Xerus).
• Mininet – Esta ferramenta é de suma importância, pois provê a criação do ambiente
virtualizado, emulando hosts, switches e links. Versão utilizada 2.2.1.2.
• OpenDaylight – Esta ferramenta faz a função de controlador e consequentemente
passa a implementar as regras de rede. Versão utilizada 0.1.1 (Hydrogen).
4.2.1 SOFTWARES UTILIZADOS
Nesta seção serão apresentadas detalhadamente as ferramentas utilizadas e
alguns recursos a serem abordados neste trabalho.
4.2.1.1 UBUNTU
O Ubuntu pode ser considerado um dos sistemas operacionais Linux mais
conhecidos, pois o mesmo traz facilidades em sua utilização, sendo compatível e
composto por diversos softwares que possibilitam a sua integral utilização em
necessidades estritamente profissionais ou acadêmicas, tais como a elaboração de
cenários e simulações.
4.2.1.2 MININET
O Mininet é uma plataforma que permite a emulação de rede, criando uma
rede virtual com switches, hosts e links com um controlador em uma única máquina
real ou virtual. Para uma prévia demonstração da sua utilização, será criada uma rede

35
virtual simples composta de três hosts e um switch OpenFlow. O comando para criar
a rede usando o Mininet está ilustrado na Figura 8:
#mn --topo single,3 --mac --switch ovsk --controller remote
Figura 8: Comando para criar a rede usando o Mininet
Fonte: Dos Autores.
Este comando define uma topologia contendo três hosts e um único switch do
tipo OpenvSwitch8, que configura os endereços MAC de cada host de modo a serem
parecidos com seus IPs, e aponta para um controlador remoto cujo endereço padrão
é o localhost. O Mininet mostra no terminal os passos que está realizando para criar
a rede virtual de acordo com os parâmetros definidos e ao final apresenta seu próprio
terminal de comando na tela, por este terminal é possível realizar a execução de vários
comandos pertinentes ao Mininet conforme exibido na Figura 9.
mininet>
Figura 9: Terminal de comando do Mininet
Fonte: Dos Autores.
Na Figura 10 é demonstrado o comando para visualizar a lista de nós
disponíveis pelo Mininet.
mininet>nodes
Figura 10: Comando para listar os nós do Mininet
Fonte: Dos Autores.
Já o comando ping ilustrado na Figura 11 é utilizado para testar a
conectividade entre hosts.
mininet>h1 ping h2
Figura 11: Comando para testar conectividade (ping) no Mininet
Fonte: Dos Autores.
8 O OVS (Open vSwitch) é um comutador virtual que permite a automatização das redes, tendo inclusive
o OpenFlow implementado. Apesar de ser um software separado, o Mininet faz uso dele para
virtualização dos switches de suas topologias.

36
Comando help expressado na Figura 12 é utilizado para visualizar outros
comandos disponíveis do Mininet.
mininet>help
Figura 12: Comando de ajuda (help) do Mininet
Fonte: Dos Autores.
O Mininet também disponibiliza um interpretador em Python que possibilita o
desenvolvimento de uma arquitetura de rede utilizando a API do software de modo
customizado, facilitando a criação de experimentos, topologias e nodes (hosts,
switches, controladores ou outros). Este mesmo interpretador será utilizado pelos
membros da equipe de forma a elaborar uma topologia específica além das
disponíveis pelo Mininet.
4.2.1.3 OPENDAYLIGHT
O software OpenDaylight (Figura 13) compreendido por Bilbao (2016), surgiu
através de um grupo de fabricantes com o intuito de criar um projeto open source
voltado a SDN. Este projeto possui o apoio da Linux Foundation e a colaboração de
várias empresas. Com este objetivo, foi iniciado o desenvolvimento de um conjunto
de tecnologias SDN, incluindo uma controladora com interfaces para a integração de
aplicações e ferramentas de gestão instalação. A linguagem de programação utilizada
no desenvolvimento e em sua execução é o Java, por tanto para a sua execução se
faz necessário que o software esteja previamente instalado no sistema operacional.
O software está disponível no site9 oficial do projeto do OpenDaylight.
Figura 13: Logo do OpenDaylight
Fonte: OPENDAYLIGHT (2013)
Para o presente trabalho este software será o controlador no conceito de SDN.
9 https://www.opendaylight.org/downloads

37
A escolha e utilização dessa ferramenta se deu devido a ser open source, ou seja,
para o aproveitamento dos recursos não se faz necessário adquirir alguma licença ou
pagamentos pelo seu uso e por possui uma plataforma de programação de redes
baseada em diferentes padrões industriais e integração com OpenFlow.
4.2.2 PREPARAÇÃO DO AMBIENTE
Para o desenvolvimento da estrutura da rede no ambiente virtual, será
abordada a mesma topologia da Figura 7 (seção 4.1), visando mostrar a mesma
estrutura física em um ambiente virtual.
4.2.2.1 INICIALIZAÇÃO DO OPENDAYLIGHT
A execução do controlador pode ser realizada pelo terminal (Figura 14) sendo
executado um script que está junto a pasta raiz do controlador.
# ./run.sh
Figura 14: Inicialização do controlador OpenDaylight
Fonte: Dos Autores.
Após a execução do script, o controlador começa a ser inicializado. Dentro de
alguns minutos, sua utilização poderá ser realizada via navegador por meio da URL
(Uniform Resource Locator), “localhost:8080” (Figura 15) ou através do terminal em
que o script foi iniciado (Figura 16).
Figura 15: Tela de autenticação do OpenDaylight via navegador
Fonte: Dos Autores.

38
Figura 16: Tela inicial do OpenDaylight via terminal
Fonte: Dos Autores.
Referente ao acesso por meio do navegador ilustrado na Figura 15, depois de
acessar a página se faz necessário informar o usuário e senha para acesso. Por
padrão o acesso é: usuário “admin” e senha “admin”.
4.2.2.2 CRIAÇÃO DA TOPOLOGIANO MININET
Será executado um script (Apêndice A) elaborado pelos membros da equipe
a fim de criar a mesma estrutura informado anteriormente (Figura 7, seção 4.1). A
execução se dá através do seguinte comando, demonstrado na Figura 17.
# python ./script_tcc.py
Figura 17: Inicialização da topologia virtual no Mininet
Fonte: Dos Autores.
Após o procedimento é iniciado o terminal do Mininet. Será executado outro
comando no terminal (representado na Figura 18) para realizar o teste de
comunicação em todos os hosts criados. Este processo realiza um ping em todos os
as instâncias virtualizadas.
mininet> pingall
Figura 18: Execução do comando Pingall no Mininet
Fonte: Dos Autores.
No Quadro 5, pode-se analisar a identificação dos hosts (Figura 18) aos
respectivos endereços IP ilustrados anteriormente (Figura 7, seção 4.1).
Quadro 5: Identificação dos hosts e endereços IP da topologia virtual
Nome do Host Endereço IP
h1 10.10.0.1
h2 10.10.0.2
h3 172.16.20.1
h4 172.16.20.2
Fonte: Dos Autores.

39
4.2.2.3 UTILIZAÇÃO DO CONTROLADOR
Após o acesso no controlador através do navegador, pode-se encontrar a
topologia criada no Mininet de modo gráfico como demonstrado na Figura 19. Torna-
se possível a organização visual dos dispositivos clicando e arrastando-os.
Figura 19: Tela inicial do OpenDaylight via navegador
Fonte: Dos Autores.
Para a criação de regras de controle de fluxos no controlador, primeiro deve-
se acessar a opção Flows do lado superior esquerdo e depois no botão Add Flow
Entry, conforme a Figura 20.
Figura 20: Criação de regras no OpenDaylight
Fonte: Dos Autores.
Com base na Figura 21, pode-se analisar as maneiras de se criar regras com
base nas ações (actions) definidas pelo controlador.

40
Figura 21: Ações de uma regra no OpenDaylight
Fonte: Dos Autores.
Para a confirmação da criação da regra é necessário definir um nome e
escolher o tipo do tratamento. Os tratamentos de fluxos disponíveis pelo controlador
se dão por meio de alguns recursos referentes às camadas de enlace, rede e de
transportes no modelo RM-OSI. As ações aplicadas em cada fluxo fazem referências
as portas reservadas do OpenFlow, conforme o Quadro 6. Será citado algumas
funções das actions nativas do controlador:
Quadro 6: Descrição de algumas ações possíveis no OpenDaylight
Actions Função
Drop Descarta o pacote.
Modify Network Destination Address Modifica o cabeçalho do pacote,
sobrescrevendo o endereço IP de destino.
Add Output Port Encaminha o pacote para outra porta de
saída do switch.
Fonte: Dos Autores.
Após às regras definidas é possível desativar a regra conforme ilustrado na
Figura 22. Caso seja necessária sua reativação o mesmo poderá ser realizado
apenas ativando a regra de fluxo na mesma tela.

41
Figura 22: Desinstalar regra de fluxo no OpenDaylight
Fonte: Dos Autores.
4.3 CASOS DE USO
Nesta seção serão abordados alguns casos de uso utilizados para demonstrar
o OpenDaylight.
4.3.1 BLOQUEIO DE COMUNICAÇÃO
Será feita uma simulação de modo que ocorra um bloqueio de comunicação
entre dois hosts. Com base na Figura 23 analisa-se a execução do comando ping e
pode-se identificar que a comunicação está funcionando entre eles.
Figura 23: Ping entre h1 e h2 no Mininet – Funcionando
Fonte: Dos Autores.
Na Figura 24 é ilustrado a tela dos parâmetros informados para realizar a
criação da regra que faz o bloqueio de todos os pacotes transmitidos do host 1 para o
host 2. Seguindo com a Figura 25, que demonstra novamente o teste do ping, exibindo
que a conexão entre os dois hosts está sendo descartada conforme realizado no
controle de fluxo.

42
Figura 24: Adicionar regra para bloquear tráfego entre h1 e h2 no OpenDaylight
Fonte: Dos Autores.
Figura 25: Ping entreh1 e h2 no Mininet– Não Funcionando
Fonte: Dos Autores.
Dentre as opções apresentadas na Figura 24 pode-se também definir um
tempo de execução para a regra. Sua definição é dada da seguinte maneira, enquanto
não houver tráfego entre a origem e o destino o tempo é contado, se houver tráfego,
que faça uso da regra, a contagem do tempo é reiniciada. A opção para realizar esta
tarefa pode ser encontrada no campo idle time out, sendo que o tempo é definido em
segundos.
4.3.2 COMUNICAÇÃO DE REDES DISTINTAS
Neste caso será realizada a conexão entre duas redes diferentes, de modo
que haja comunicação entre elas.
Inicialmente será demonstrado que a comunicação entre as redes distintas
não é possível, conforme ilustrado na Figura 26.

43
Figura 26: Comunicação entre redes distintas no Mininet não funcional
Fonte: Dos Autores.
Para realizar este procedimento é necessário definir um gateway que faça o
roteamento entre as redes. O controlador OpenDaylight pode prover essa
funcionalidade, tendo que configurá-lo com um IP válido de cada uma das redes. Essa
configuração poderá ser realizada acessando o botão Add Gateway IP Address
(Figura 27).
Figura 27: Adicionar Gateway IP Address
Fonte: Dos Autores.
Ao selecionar a opção, deve-se especificar um nome e um endereço IP que
deseja-se definir ao controlador. No ambiente em análise exposto na Figura 7, seção
4.1, torna-se necessário adicionar um gateway para a rede 10.10.0.0/24 e
172.16.20.0/24 conforme ilustrado na Figura 28 e Figura 29.
Figura 28: Adicionar Gateway rede 10.10.0.0/24 no OpenDaylight
Fonte: Dos Autores.

44
Figura 29: Adicionar Gateway rede 172.16.20.0/24 no OpenDaylight
Fonte: Dos Autores.
Vale ressaltar que além desse recurso configurado, as máquinas devem ter
uma rota padrão que destine seus pacotes aos gateways definidos anteriormente. No
ambiente proposto, essa rota foi antecipadamente definida no script que inicia a
topologia no Mininet.
Contudo, ao tentar executar a comunicação entre o host 1 e o host 3
novamente, é possível validar o sucesso na conexão (Figura 30).
Figura 30: Comunicação entre redes distintas no Mininet funcional
Fonte: Dos Autores.
4.3.3 ALTERAR COMUNICAÇÃO DE ENDEREÇO DE IP DO DESTINO
Nesta simulação será realizada a alteração de endereço de destino, de modo
que o host 1 tentará se comunicar com o host 3, mas sua comunicação será
transferida para o host 4. Para realização do teste, primeiramente será criado um
serviço web no host 4, ilustrado na Figura 31.
Figura 31: Iniciar Serviço Web
Fonte: Dos Autores.
Após iniciar o serviço, será feito um teste de comunicação com o host 3 na

45
porta 80, da qual iniciou-se o serviço web, por meio do comando Telnet10. Na Figura
32, pode-se analisar que a comunicação não é estabelecida.
Figura 32: Teste de Telnet com H3 no Mininet – Conexão Recusada
Fonte: Dos Autores.
Para alterar o destino da comunicação, deve-se criar uma regra que
baseando-se na origem e destino do pacote, o controlador irá alterar o cabeçalho que
identifica o IP de destino (Figura 33).
Figura 33: Regra de alteração do destino no OpenDaylight
Fonte: Dos Autores.
10 Protocolo de rede que possibilita comunicações bidirecionais.

46
Deve-se realizar outra regra, onde a comunicação de resposta do host 4, seja
mascarada como o host 3, para que o host 1 aceite o pacote e estabeleça a conexão.
Para essa segunda regra, será manipulado o cabeçalho do pacote IP alterando a
origem, ilustrado na Figura 34.
Figura 34: Regra de alteração da origem no OpenDaylight
Fonte: Dos Autores.
Será demonstrado o mesmo teste ilustrado na Figura 32, de modo que possa
haver a comunicação entre o host 1 e host 3 (Figura 35).

47
Figura 35: Teste de Telnet com H3 no Mininet – Conexão Estabelecida
Fonte: Dos Autores.
Pode-se analisar que após as definições das regras o controlador possibilitou
a alteração do cabeçalho do pacote, de modo que comunicação não foi tratada no
host 3, mas no host 4.
4.3.4 SWITCH EM MODO REATIVO
Para este caso, será implementado no controlador um código desenvolvido
em Java, vide Apêndice B e Apêndice C, do qual tem por objetivo restringir a
comunicação entre duas máquinas através de uma porta específica. Essa atividade
será efetuada utilizando o funcionamento reativo dos switches.
Na implementação de códigos, são instalados pacotes de softwares, também
chamados no OpenDaylight de bundles.
Inicialmente, no controlador, é preciso parar alguns serviços que podem
influenciar no tráfego a ser manipulado pelo bundle desenvolvido. Dessa forma, torna-
se necessário identificar o código ID (IDentificação) dos pacotes de software simple
forwarding e load balancer conforme ilustrado nas Figura 36 e Figura 37.
Figura 36: Identificar ID do pacote de software simple forwarding no OpenDaylight
Fonte: Dos Autores.
Figura 37: Identificar ID do pacote de software load balancer no OpenDaylight
Fonte: Dos Autores.
Deve-se parar o pacote de código 66 ilustrado na Figura 36 e o pacote de
código 16 ilustrado na Figura 37. Para tal, será aplicado o comando stop seguido do
ID identificado, conforme Figura 38.
Figura 38: Parar os serviços de ID 16 e 66 no OpenDaylight
Fonte: Dos Autores.
Para instalação do pacote de software desenvolvido, torna-se essencial a
aplicação Java compilada em um arquivo de extensão JAR (Java ARchive). Com o

48
código devidamente compilado, deve-se no controlador informar a instalação do
respectivo arquivo, conforme ilustrado na Figura 39.
Figura 39: Instalar pacote de software no OpenDaylight
Fonte: Dos Autores.
Após instalado o pacote, será exibido o ID do bundle (Figura 39), do qual
deverá ser utilizado para iniciar o pacote recém instalado com o comando start (Figura
40).
Figura 40: Iniciar pacote de software no OpenDaylight
Fonte: Dos Autores.
Conforme mencionado anteriormente, para esse caso será utilizada uma
topologia diferente. De acordo com o descrito no capítulo 4.2.1.2, a ferramenta Mininet
provê a criação de uma topologia virtual através de comandos, logo a topologia pode
ser iniciada com o comando ilustrado na Figura 41.
Figura 41: Iniciar topologia linear com o Mininet
Fonte: Dos Autores.
Para essa ocasião, utiliza-se o uso de uma topologia linear, que faz uso de
dois switches interligados e com um host conectado em cada um dos equipamentos,
ficando disposta conforme Figura 42. Nessa situação, o papel do h1 remete ao IP
10.0.0.1 e o h2 ao IP 10.0.0.2. Os switches estão denominados como s1 e s2.
Figura 42: Visualização da topologia linear do caso de uso 4
Fonte: Dos Autores.
O código instalado no controlador foi desenvolvido baseando-se no ambiente
em simulação. De tal maneira, foram definidos parâmetros que darão forma a regra
de fluxo. A regra a ser estudada nesse caso, utiliza como critérios a porta 8888 e os
hosts h1 e h2, pré-definidos no código da Apêndice C e brevemente expostos a seguir.
private static final int Porta_Servico = 8888;
private static final String h1_IP = "10.0.0.1";

49
Fazendo jus aos critérios, o código tem por objetivo bloquear o tráfego quando
a origem for o h1 destinando um pacote para o h2 na porta 8888.
Para representar uma conexão que atenda a esses requisitos, no terminal em
que foi iniciado no Mininet, faz-se necessário utilizar mais um recurso suportado pela
ferramenta, o XTerm11, para que o teste de comunicação possa ser demonstrado com
maior nitidez. Ilustrado na Figura 43, será inicializado o emulador de terminal para os
respectivos hosts.
Figura 43: Iniciando o XTerm no h1 e h2 no Mininet
Fonte: Dos Autores.
Ao término da execução, serão abertas duas janelas que referem-se aos hosts
1 e 2. Na janela do h2, é necessária a execução do Netcat12 para que a máquina
possa receber uma comunicação na porta utilizada para o teste (8888). O comando
executado segue exposto na Figura 44.
Figura 44: Abrir conexão na porta 8888 no h2 com o Netcat
Fonte: Dos Autores.
Para enviar um pacote do h1 ao h2 na porta 8888, utiliza-se ainda o Netcat,
porém de forma a encaminhar um pacote com o texto "Hello h2" caso a conexão seja
estabelecida. O comando executado segue exibido na Figura 45.
Figura 45: Enviar pacote do h1 para o h2 na porta 8888 com o Netcat
Fonte: Dos Autores.
Logo que o bundle desenvolvido está iniciado, a comunicação entre as
máquinas não será estabelecida, e no controlador será notificada uma mensagem
informando sobre a tentativa de tráfego, conforme Figura 46.
Figura 46: Notificação da tentativa de tráfego exibida no OpenDaylight
Fonte: Dos Autores.
Os switches não apresentam nenhuma regra de fluxo instalada ao iniciar a
11 Emulador de terminal.
12 Ferramenta que faz uso do protocolo TCP/IP para enviar e receber conexões de rede.

50
topologia do Mininet, e passaram a implementar a regra comentada na ilustração
Figura 46somente quando o tráfego gerado atende aos requisitos do código que foram
descritos anteriormente. Visto que o Open vSwitch é o tipo de switch utilizado na
topologia, possibilita-se a exibição das tabelas de fluxo dos equipamentos iniciados
através de comandos. No presente cenário, segundo a informação exibida na Figura
46, a regra foi implementada no switch de ID final 01, fazendo referência ao s1 da
topologia. Para visualizar que a regra de fluxo foi instalada, será executado o comando
ilustrado na Figura 47.
Figura 47: Exibir fluxos do s1 com comandos do Open vSwitch
Fonte: Dos Autores.
Determinada essa metodologia de instalação de novas regras de fluxo, com o
uso do código implementado é identificado o funcionamento reativo, do qual foi
descrito anteriormente na seção 3.2.
Com o objetivo de justificar que o bloqueio foi feito através do código
desenvolvido, será utilizado o ID do bundle identificado na Figura 39 para parar pacote
de software anteriormente instalado, conforme exibido na Figura 48.
Figura 48: Parar pacote de software instalado no OpenDaylight
Fonte: Dos Autores.
Por fim, ao parar o pacote e executar os mesmos comandos demonstrados
na Figura 44 e na Figura 45, respectivamente, será exibido o retorno esperado no
terminal do h2, conforme exposto na Figura 49.
Figura 49: Conexão estabelecida entre h1 e h2 na porta 8888 com o Netcat
Fonte: Dos Autores.
4.3.5 OUTROS CASOS DE USO
Através de ambientes com o uso do OpenDaylight ainda na versão Hydrogen,
é possível criar situações que expõem a importância de determinados fluxos,
alterando os bits de ToS (Type of Service), possibilitando ao switch o entendimento
de qual pacote deverá ser tratado primeiramente.

51
Outras ações ainda são possíveis quando um fluxo compatível com alguma
regra for identificado, como por exemplo as saídas não OpenFlow. Em tais situações,
pode-se exemplificar o uso das actions Hardware Path e Flood, onde o controlador faz
com que o switch encaminhe o pacote de forma padrão, analisando por exemplo as
tabelas CAM (Content Addressable Memory), em qual porta está o destinatário do
pacote, para então tomar a decisão de direcionamento.
De acordo com a necessidade, bem como a alteração dos cabeçalhos IP
(origem/destino), também é possível implementar ações direcionadas a VLAN (Virtual
Local Area Network), tratando mudança de ID e prioridades.
4.4 DIFICULDADES ENCONTRADAS
Para o desenvolvimento dos casos de uso, tornou-se necessário a
implementação do conceito de redes junto a plataforma OpenDaylight, de forma a
demonstrar o funcionamento centralizado da arquitetura. A utilização desse modelo
de tecnologia requer em muitos casos demonstrações que se remetem análises de
baixo nível, onde a comprovação e uso da ferramenta costumeiramente acaba sendo
pouco intuitiva para ilustração acadêmica.
Com base nessa necessidade identificada, com o decorrer da preparação e
pesquisa do ambiente, foi necessário fazer o uso de uma versão inicial do
OpenDaylight (Hydrogen), logo que tal possui uma interface que favorece o
esclarecimento do conceito de redes definidas por software.
Ao longo da escolha dessa versão, foram exploradas outras versões da
mesma plataforma como a Boron e a Berylium e até mesmo outros controladores
como Pox, Nox, Floodlight e Onos, que possibilitaram aos acadêmicos uma
visibilidade de outras ferramentas atualmente disponíveis no mercado, constituindo
um panorama de uso de plataformas SDN e favorecendo o entendimento do conceito
a fins de implementá-lo de forma mais efetiva.
Em status geral, é possível identificar controladores complexos, que exigem
do administrador o conhecimento afinco em relação à linguagem na qual a plataforma
foi desenvolvida, as métricas e funcionamento dos protocolos e recursos de redes e
em algumas situações, como utilizar arquiteturas que podem ser incorporadas ao
controlador, como é o caso da REST (Representational State Transfer), que em
algumas versões pode ser utilizada para incrementar a inserção, modificação e
remoção de fluxos.

52
Agregando os conceitos de software defined networking embasados no
capítulo de redes de computadores, possibilitou-se a projeção de alguns casos de
uso, a fim de demonstrar o funcionamento do controle centralizado, promovendo a
implementação de regras de fluxo em switches virtualizados, com o objetivo de gerir
o tráfego entre máquinas virtuais distintas.
Em suma, as situações exploradas remetem a ocasiões relativamente
convencionais, porém implementadas através do uso de plataformas gratuitas e
usuárias do conceito principal do presente trabalho.
Exibe-se o funcionamento das aplicações utilizadas para preparação do
ambiente virtualizado, de forma a descrevê-las e ilustrá-las.
Os casos tendem a ser descritivos e simulam bloqueios e modificações de
pacotes de rede, de forma a direcionar ou restringir comunicações. Agregam-se
também outras situações que poderiam ser simuladas utilizando a plataforma, das
quais são descritas superficialmente como outros casos possíveis.

53
5 CONSIDERAÇÕES FINAIS
Neste capítulo serão apresentadas as conclusões e recomendações para
trabalhos futuros.
5.1 CONCLUSÕES
Em diversas situações é possível identificar o importante papel da inovação
através de novos softwares, e com o conceito de SDN as redes também passam a se
destacar nesse quesito.
Justamente porque o embasamento para aprofundar-se nesse conceito
permanece sendo “redes de computadores”, propiciou-se o entendimento do
funcionamento de uma topologia de rede, através dos métodos de comunicação,
incluindo e explanando referências a protocolos, meios de conexão, padrões
internacionais, e outras informações que agregam valor a infraestrutura
convencionalmente utilizada.
Diante da assimilação, tornou-se possível averiguar os diferentes recursos e
funcionamento do conceito SDN. Com as características devidamente analisadas,
permitiu-se justificar o uso de tal inovação tecnológica, cujo presente trabalho remete
ao protocolo OpenFlow, e esclarece o funcionamento da sistemática de conexão entre
o controlador e os ativos de rede. Em fato, a absorção de como as tabelas de fluxo,
portas e canal OpenFlow trabalham, são requisitos para implementação desses novos
recursos.
A diversidade consequentemente proposta ao aderir às redes definidas por
softwares decorreu na identificação de diferentes plataformas de controle, onde os
sistemas se aplicam em diferentes necessidades de negócio e experiência do
administrador de redes, visto que a complexidade dos controladores difere em
portabilidade e no número de funcionalidades disponíveis, bem como a linguagem de
programação da qual o centro de controle foi desenvolvido. Apesar do grande leque
de soluções, optou-se pelo uso do OpenDaylight, do qual adequou-se ao uso da
linguagem Java e é disponibilizado de forma open source, atendendo às necessidades
para demonstração do tema proposto.
Oportunizou-se com o conhecimento de redes de computadores, SDN,
OpenDaylight e outras ferramentas agregadas, a criação de um ambiente virtual que
ratifica de forma coerente como a emergente tecnologia funciona, destacando

54
algumas atividades passíveis de serem executadas através do centro de controle.
Ilustra-se o cenário utilizando uma topologia de pequeno porte, de forma a deixar clara
a abordagem almejada através do OpenDaylight em conjunto ao OpenFlow.
Considerando os objetivos do trabalho em relação ao conceito exposto,
conclui-se que o modelo de redes através de software tende a ser extremamente
funcional, sendo necessário adequá-lo de acordo com a necessidade de negócio e
exigindo em alguns casos, uma equipe capaz de tratar o desenvolvimento e a
operação como mantenedora da topologia de rede disposta.
Contudo, deve-se ter a perspicácia de que as implementações de ferramentas
semelhantes em grandes amplitudes exigem uma constante dedicação também dos
mantenedores do protocolo OpenFlow e controladores, a julgar por ser um conceito
do qual sua difusão está em andamento. Processo este que vem enriquecendo com
o passar do tempo, e contando com o apoio do qual tem recebido, deve ingressar ao
cotidiano dos administradores em breve.
Inovações como SDN permitem agregar valores significativos para as
empresas, logo que a tecnologia tem valor substancial para a competitividade e
potenciais ganhos estratégicos, através da simplificação e flexibilidade do controle das
redes e possibilidade de aumentar as camadas de segurança, permitindo ressaltar
com seu perceptível diferencial, a importância do conceito.
5.2 RECOMENDAÇÕES PARA TRABALHOS FUTUROS
São recomendações para trabalhos futuros:
• Desenvolver um ambiente utilizando o OpenDaylight integrado com o OpenStack
Neutron.
• Explorar os recursos do NeXt UItoolkit em conjunto a interface DLUX do
OpenDaylight projetando melhores visibilidades da topologia de rede.
• Elaborar um comparativo de funcionamento do OpenDaylight com outros
controladores.
• Evidenciar o funcionamento das redes definidas por software através de uma
aplicabilidade real em infraestrutura física.

55
REFERÊNCIAS
BILBAO, Nerea. Conocemos OpenDaylight, el proyecto de SDN open source
“más grande del mundo”. 2016. Disponível em: <http://goo.gl/8bzsh4>. Acesso
em: 16 ago. 2016.
CISCO. All classes. 2014. Disponível em:<https://goo.gl/KNWqoc>. Acesso em: 17
out. 2016.
COMER, Douglas E.. Interligação de redes com TCP/IP: princípios, protocolos e
arquitetura. Rio de Janeiro: Elsevier, 2006.
DÜR, Franck. Developing OSGi Components for OpenDaylight. 2014. Disponível
em: <https://goo.gl/44Lfi8>. Acesso em: 17 out. 2016.
______. Reactive Flow Programming with OpenDaylight. 2014. Disponível em:
<https://goo.gl/dmVrvq>. Acesso em: 17 out. 2016.
FALSARELLA, Douglas. SDN (Software Defined Network) e o futuro das redes.
2012. Disponível em: <http://goo.gl/ZvRhBj>. Acesso em: 18 maio 2016.
FOROUZAN, Behrouz A.. Comunicação de dados e redes de computadores. 4.
ed. São Paulo: McGraw-Hill, 2008.
HAYDEN, Matt. Aprenda em 24 horas redes. Rio de Janeiro: Campus, 1999.
KLEIS, Elton Gastardelli. Redes Definidas por SW I: aplicação para diferenciação
de caminhos. 2015. Disponível em: <http://goo.gl/adp0ci>. Acesso em: 26 maio
2016.
KUROSE, James F.; ROSS, Keith W.. Redes de computadores e a internet: uma
abordagem top-down. 3. ed. São Paulo: Pearson Addison Wesley, 2006.
LOBATO, Antonio Gonzalez Pastana; FIGUEIREDO, Ulisses da Rocha; ALVES,
Leandro. Redes definidas por software. 2013. Disponível em:
<http://goo.gl/p6kNTr>. Acesso em: 23 maio 2016.
LUNARDI, Marco Agisander. Redes de computadores: prático e didático. Rio de
Janeiro: Ciência Moderna, 2007.
MARQUES, Wilson Soler. TCP-IP: projetando redes. Rio de Janeiro: Brasport, 2000.
MORAES, Alexandre Fernandes de. Redes de computadores: fundamentos. 7. ed.
São Paulo: Érica, 2010.
ODOM, Wendel. CCENT/CCNA ICND 1: guia oficial de certificação do exame. 2. ed.
Rio de Janeiro: Alta Books, 2008.
ONF. Open Network Foudation. Software-Defined Networking: the new norm for
networks. [s.l.]: Open Network Foudation, 2012. Disponível em:

56
<https://goo.gl/I4yvLA>. Acesso em: 18 maio 2016.
______. What is ONF?. [s.l.]: Open Network Foudation, 2013. Disponível em:
<https://goo.gl/nazcTQ>. Acesso em: 18 maio 2016.
______. OpenFlow switch specification. [s.l.]: Open Network Foundation, 2014.
Disponível em: <https://goo.gl/RRdFCm>. Acesso em: 23 maio 2016.
OPENDAYLIGHT. Brand identity guide lines. 2013. Disponível em:
<https://goo.gl/KoCwng>. Acesso em: 01 set. 2016.
PETERSON, Larry L.; DAVIE, Bruce S.. Redes de computadores: uma abordagem
de sistemas. Rio de Janeiro: Elsevier, 2004.
REDES definidas por software: uma visão sobre o novo paradigma de redes. In:
INFOBRASIL VII CONGRESSO TECNOLÓGICO. 2014, Fortaleza. [s.l.]: InfoBrasil,
2014. p. 243-249. Disponível em: <https://goo.gl/6SMN6p>. Acesso em: 18 maio
2016.
REINA, Eduard. How to control a new network paradigm: An overview of
OpenDaylight SDN Platform. 2015. 210 f. (Dissertação) Escola Tècnica Superior
d’Enginyeria de Telecomunicació de Barcelona, Universitat Politècnica de Catalunya.
Barcelona: 2015. Disponível em: <https://goo.gl/6CCNjG>. Acesso em: 18 out. 2016.
SDN: um novo paradigma?. Informática em revista paraíba. Paraíba, ano 1, n. 3, p.
10-11, jun./2014. Disponível em: <https://goo.gl/aueNPP>. Acesso em: 18 maio
2016.
SOARES, Luiz Fernando G.; LEMOS, Guido; COLCHER, Sergio. Redes de
computadores: das LANs, MANs e WANs às redes ATM. 2. ed. Rio de Janeiro:
Campus, 1995.
TANENBAUM, Andrew S.; WETHERALL, David. Redes de computadores. 5. ed.
São Paulo: Person Prentice Hall, 2011.

APÊNDICE A – TOPOLOGIA MININET

#!/usr/bin/python
from mininet.net import Mininet
from mininet.node import Controller, RemoteController, OVSKernelSwitch,
UserSwitch, Host
from mininet.cli import CLI
from mininet.log import setLogLevel
from mininet.link import Link, TCLink, Intf
def topology():
net = Mininet(controller=RemoteController, switch=OVSKernelSwitch)
print "Adicionando Hosts"
h1 = net.addHost('h1', cls=Host, ip='10.10.0.1/24',
mac='00:00:00:00:00:01', defaultRoute='via 10.10.0.254')
print "Adicionando Switches"
s1 = net.addSwitch('s1', mac='00:00:00:00:00:11')
s2 = net.addSwitch('s2', mac='00:00:00:00:00:12')
print "Adicionando Controlador"
c7 = net.addController('c7',controller=RemoteController,ip='127.0.0.1',
port=6633)
print "Criando link entre Switches e Hosts"
net.addLink(s1, h1)
net.addLink(s1, h2)
net.addLink(s2, h3)

net.addLink(s2, h4)
net.addLink(s1, s2)
print "Inicializando a rede"
net.build()
s1.start([c7])
s2.start([c7])
c7.start()
h1.cmd('vconfig add h1-eth0 10')
print "Confirmando definicoes"
CLI(net)
print "Parando a rede"
net.stop()
if __name__ == '__main__':
setLogLevel('info')
topology()

APÊNDICE B – ACTIVATOR.CLASS

package tcc.Danilo_Jefferson.casoquatro;
import java.util.Dictionary;
import java.util.Hashtable;
import org.apache.felix.dm.Component;
import org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase;
import
org.opendaylight.controller.sal.flowprogrammer.IFlowProgrammerService;
import org.opendaylight.controller.sal.packet.IDataPacketService;
import org.opendaylight.controller.sal.packet.IListenDataPacket;
import org.opendaylight.controller.switchmanager.ISwitchManager;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Activator extends ComponentActivatorAbstractBase {
private static final Logger log =
LoggerFactory.getLogger(PacketHandler.class);
public Object[] getImplementations() {
log.trace("Getting Implementations");
Object[] res = { PacketHandler.class };
return res;
}
public void configureInstance(Component c, Object imp, String
containerName) {
log.trace("Configuring instance");
if (imp.equals(PacketHandler.class)) {
// Define exported and used services for PacketHandler component.

Dictionary<String, Object> props = new Hashtable<String, Object>();
props.put("salListenerName", "mypackethandler");
// Export IListenDataPacket interface to receive packet-in events.
c.setInterface(new String[] {IListenDataPacket.class.getName()},
props);
// Need the DataPacketService for encoding, decoding, sending data
packets
c.add(createContainerServiceDependency(containerName).setService(IDataPacketS
ervice.class).setCallbacks("setDataPacketService",
"unsetDataPacketService").setRequired(true));
// Need FlowProgrammerService for programming flows
c.add(createContainerServiceDependency(containerName).setService(
IFlowProgrammerService.class).setCallbacks(
"setFlowProgrammerService", "unsetFlowProgrammerService")
.setRequired(true));
// Need SwitchManager service for enumerating ports of switch
c.add(createContainerServiceDependency(containerName).setService(
ISwitchManager.class).setCallbacks(
"setSwitchManagerService", "unsetSwitchManagerService")
.setRequired(true));
}
}
}

APÊNDICE C – PACKETHANDLER.CLASS

package tcc.Danilo_Jefferson.casoquatro;
import java.net.InetAddress;
import java.net.UnknownHostException;
import java.util.LinkedList;
import java.util.List;
import org.opendaylight.controller.sal.action.Action;
import org.opendaylight.controller.sal.action.Output;
import org.opendaylight.controller.sal.action.SetDlDst;
import org.opendaylight.controller.sal.action.SetDlSrc;
import org.opendaylight.controller.sal.action.SetNwDst;
import org.opendaylight.controller.sal.action.SetNwSrc;
import org.opendaylight.controller.sal.action.Drop;
import org.opendaylight.controller.sal.core.ConstructionException;
import org.opendaylight.controller.sal.core.Node;
import org.opendaylight.controller.sal.core.NodeConnector;
import org.opendaylight.controller.sal.flowprogrammer.Flow;
import
org.opendaylight.controller.sal.flowprogrammer.IFlowProgrammerService;
import org.opendaylight.controller.sal.match.Match;
import org.opendaylight.controller.sal.match.MatchType;
import org.opendaylight.controller.sal.packet.Ethernet;
import org.opendaylight.controller.sal.packet.IDataPacketService;
import org.opendaylight.controller.sal.packet.IListenDataPacket;
import org.opendaylight.controller.sal.packet.IPv4;
import org.opendaylight.controller.sal.packet.Packet;
import org.opendaylight.controller.sal.packet.PacketResult;
import org.opendaylight.controller.sal.packet.RawPacket;
import org.opendaylight.controller.sal.packet.TCP;
import org.opendaylight.controller.sal.utils.EtherTypes;
import org.opendaylight.controller.sal.utils.Status;
import org.opendaylight.controller.switchmanager.ISwitchManager;
import org.slf4j.Logger;

import org.slf4j.LoggerFactory;
public class PacketHandler implements IListenDataPacket {
private static final Logger log =
LoggerFactory.getLogger(PacketHandler.class);
private static final int Porta_Servico = 8888;
private IDataPacketService dataPacketService;
private IFlowProgrammerService flowProgrammerService;
private ISwitchManager switchManager;
private InetAddress h1Address;
private InetAddress h2Address;
static private InetAddress intToInetAddress(int i) {
byte b[] = new byte[] { (byte) ((i>>24)&0xff), (byte) ((i>>16)&0xff), (byte)
((i>>8)&0xff), (byte) (i&0xff) };
InetAddress addr;
try {
addr = InetAddress.getByAddress(b);
} catch (UnknownHostException e) {
return null;
}
return addr;
}
public PacketHandler() {
try {
h1Address = InetAddress.getByName(h1_IP);

log.error(e.getMessage());
}
try {
h2Address = InetAddress.getByName(h2_IP);
log.error(e.getMessage());
}
}
void setDataPacketService(IDataPacketService s) {
log.trace("Set DataPacketService.");
dataPacketService = s;
}
void unsetDataPacketService(IDataPacketService s) {
log.trace("Removed DataPacketService.");
if (dataPacketService == s) {
dataPacketService = null;
}
}
void setFlowProgrammerService(IFlowProgrammerService s) {
log.trace("Set FlowProgrammerService.");
flowProgrammerService = s;
}
void unsetFlowProgrammerService(IFlowProgrammerService s) {
log.trace("Removed FlowProgrammerService.");
if (flowProgrammerService == s) {
flowProgrammerService = null;

}
}
void setSwitchManagerService(ISwitchManager s) {
log.trace("Set SwitchManagerService.");
switchManager = s;
}
void unsetSwitchManagerService(ISwitchManager s) {
log.trace("Removed SwitchManagerService.");
if (switchManager == s) {
switchManager = null;
}
}
@Override
public PacketResult receiveDataPacket(RawPacket inPkt) {
log.trace("Received data packet.");
NodeConnector ingressConnector = inPkt.getIncomingNodeConnector();
Node node = ingressConnector.getNode();
Packet l2pkt = dataPacketService.decodeDataPacket(inPkt);
if (l2pkt instanceof Ethernet) {
Object l3Pkt = l2pkt.getPayload();
if (l3Pkt instanceof IPv4) {
IPv4 ipv4Pkt = (IPv4) l3Pkt;
Object l4Datagram = ipv4Pkt.getPayload();
InetAddress clientAddr = intToInetAddress(ipv4Pkt

.getSourceAddress());
InetAddress dstAddr = intToInetAddress(ipv4Pkt
.getDestinationAddress());
if (h2Address.equals(dstAddr) && h1Address.equals(clientAddr)) {
if (l4Datagram instanceof TCP) {
TCP tcpDatagram = (TCP) l4Datagram;
int clientPort = tcpDatagram.getSourcePort();
int dstPort = tcpDatagram.getDestinationPort();
if (dstPort == Porta_Servico) {
Match match = new Match();
match.setField(MatchType.DL_TYPE, (short) 0x0800);
match.setField(MatchType.NW_PROTO, (byte) 6);
match.setField(MatchType.NW_SRC, h1Address);
match.setField(MatchType.NW_DST, h2Address);
match.setField(MatchType.TP_DST, (short) Porta_Servico);
List<Action> actions = new LinkedList<Action>();
actions.add(new Drop());
Flow flow = new Flow(match, actions);
flow.setIdleTimeout((short) 10);
flowProgrammerService.addFlow(node, flow);
System.out.println("Tentativa de acesso a porta
"+Porta_Servico+", vindo da máquina h1 ("+h1_IP+") para h2 ("+h2_IP+")

Bloqueado.");
System.out.println("Regra instalada no Switch - ID: " +
node.getNodeIDString());
}
}
}
return PacketResult.KEEP_PROCESSING;
}
}
return PacketResult.IGNORED;
}
}

APLICAÇÃO DO CONCEITO DE SOFTWARE DEFINED NETWORKING EM AMBIENTE VIRTUALIZADO: UMA ABORDAGEM DO SOFTWARE OPENDAYLIGHT UTILIZANDO O PROTOCOLO OPENFLOW

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie APLICAÇÃO DO CONCEITO DE SOFTWARE DEFINED NETWORKING EM AMBIENTE VIRTUALIZADO: UMA ABORDAGEM DO SOFTWARE OPENDAYLIGHT UTILIZANDO O PROTOCOLO OPENFLOW

Ähnlich wie APLICAÇÃO DO CONCEITO DE SOFTWARE DEFINED NETWORKING EM AMBIENTE VIRTUALIZADO: UMA ABORDAGEM DO SOFTWARE OPENDAYLIGHT UTILIZANDO O PROTOCOLO OPENFLOW (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

APLICAÇÃO DO CONCEITO DE SOFTWARE DEFINED NETWORKING EM AMBIENTE VIRTUALIZADO: UMA ABORDAGEM DO SOFTWARE OPENDAYLIGHT UTILIZANDO O PROTOCOLO OPENFLOW