Universidade Federal Fluminense
Instituto de Computação
Departamento de Ciência da Computação
Jefferson Marins Lessa
IMPLEMENTAÇÃO DE UM CONTROLADOR EM
REDES DEFINIDAS POR SOFTWARE
Niterói-RJ
2017
ii
JEFFERSON MARINS LESSA
IMPLEMENTAÇÃO DE UM CONTROLADOR EM REDES DEFINIDAS POR SOFTWARE
Trabalho submetido ao Curso de Bacharelado em Ciência da Computação da Universidade Federal Fluminense como requisito parcial para a obtençãoo do título de Bacharel em Ciência da Computação.
Orientador: Prof. Célio Vinicius Neves de Albuquerque
Niterói-RJ 2017
Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF
L638 Lessa, Jefferson Marins
Implementação de um controlador em redes definidas por software / Jefferson Marins Lessa. – Niterói, RJ : [s.n.], 2017.
57 f.
Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.
Orientador: Célio Vinicius Neves de Albuquerque.
1. Rede definida por software. 2. Rede de computadores. 3. Openflow. I. Título.
CDD 004.69
iv
Dedico esse trabalho a todos que acreditaram e me apoiaram nessa jornada da minha gra-duação.
v
Agradecimentos
Aos meus pais, Roberto e Cláudia e meu irmão, Leonardo, pelo apoio incondicional durante a realização da minha graduação, sempre me apoiando moralmente, de forma a torná-los indispensáveis em minha vida.
À minha esposa e grande amiga, Camilla Bittencourt, que em todos estes anos tem me acompanhado de diversas formas, sendo minha companheira, me apoiando, incenti-vando e acreditando em mim.
A todos os familiares de minha esposa, meus sogros Anderson e Sandra que muitas vezes, na ausência de meus familiares, me acolheram como filho e me aconselharam e apoiaram durante toda minha vida acadêmica.
Ao professor e orientador, Dr. Celio Albuquerque, por todo o apoio e me aceitar como aluno orientado. Por incentivar toda a minha produção acadêmica e estar sempre disponível para sanar dúvidas e dificuldades que surgiram durante ao desenvolvimento do Projeto.
Aos professores do Instituto de Computação, em especial, Isabel Rosseti, Esteban Clua, Luis Antônio Kowada, Daniel de Oliveira, Diego Passos, John Reed, Regina Leal e Anselmo Montenegro. Pois sem os incentivos e exemplo dados durante os anos de estudo a conclusão deste curso não seria possível.
Aos amigos da UFF e do STI em especial, Mateus Pelegrino, Evandro Mendonça, Augusto Consulmagnos, Rozana Moreira, Julius Caffaro e Cafer Cruz por estarem sempre me apoiando, seja em minha vida acadêmica, nos estudos, trabalhos ou comemorações.
Aos amigos das empresas em que trabalhei, em especial a Leandro Pacheco, Ar-naldo Fernandes e Bruno Cruz, pois foram mentores excelentes e fundamentais em minha formação profissional.
A todos os outros amigos e familiares, que possuem um significado muito impor-tante em minha vida.
vi
E por fim, à Universidade Federal Fluminense, por me proporcionar todo o apren-dizado, experiência e amigos que continuarão por toda a vida.
vii
Resumo
A crescente necessidade de expansão das redes de computadores criou um novo desafio para a comunidade mundial de desenvolvedores de redes. Com o crescente uso da Internet, estando presente em todos os níveis da sociedade, como governos, empresas e domicílios, a sensibilidade de se alterar e atualizar o hardware responsável pela rede mundial de computadores aumentou consideravelmente, haja vista que um erro poderia compremeter toda a estrutura de comunicação do mundo.
Com a ideia de aumentar os recursos de programação dos dispositivos de redes, surgiu a proposta do Openflow. Essa proposta permitia, entre outras coisas, o controle do fluxo dados por uma aplicação de software. Então surgiu o nome Redes Definidas por Software ou Software Defined Networking (SDN).
As Redes Definidas por Software têm como premissa básica separar os planos de controle, de administração e de dados. Com isso os dispositivos de rede passariam a ser responsáveis apenas pelo encaminhamento de dados e um novo elemento entraria no cenário, o controlador SDN, que tem o papel de conhecer e controlar toda a rede, orquestrando a comunicação dos elementos. Os administradores da rede passariam a administra-la através de uma central de controle e comando, facilitando a administração. Outra tecnologia que ajudou na popularidade da arquitetura SDN foi a virtualiza-ção. O conceito de Virtualização das Funções da Rede ou Network Functions
Virtualiza-tion (NFV), que é focado no provisionamento de novos serviços e funções de rede virtuais
como firewalls ou load balancers, junto ao controle proporcionado pelo controlador, foram adotados largamente pela indústria de redes. O uso dssas tecnologias alinhadas, além de aumentar velocidade no provisionamento de novos elementos de rede também diminuem os custos operacionais das empresas [17].
Com isso em mente, esse trabalho propõe a demonstração do uso de um controlador SDN em um ambiente de rede virtual. A proposta é que as ações tomadas na rede sejam
viii
refletidas no controlador e os comandos executados no controlador impactem a rede.
Palavras-chave: Redes Definidas por Software, Software Defined Networking, SDN,
ix
Abstract
The growing need to expand computer networks has created a new challenge for the global network developer community. With the increasing use of the internet, being present in all levels of society, such as governments, companies and houses, the sensiti-vity of altering and updating the network responsible for the global computer network has increased, since a simple mistake coud compromise the entire global communication structure.
With the idea of increasing the programming resources of the network devices, the Openflow proposal came up. This proposal allowed, among other things, control of the network flow by a software application, hence the name Software Defined Network (SDN). The Software Defined Networks have the basic premise to separating the plans of control, administration and data. This means that the network devices would only be responsible for data transmission and a new element would enter the scenario, the SDN controller, which has the role of knowing and controlling the whole network, orchestrating the communication of the elements. The administrator for the network would manage it through a central control and command, facilitating the control and reducing the risks of errors.
Another technology that helped increase the popularity of SDN was virtualization. The concept of Network Functions Virtualization (NFV), which focuses on the provision of new services and virtual network functions such as firewalls or load balancers, along with the control provided by the controller have been widely adopted by the network industry. These technologies aligned in addition to speed in provisioning also lowered the operating costs of companies.
With this in mind, this work proposes the demonstration of the use of a SDN controller next to a virtual network. The proposal is that actions taken on the network are reflected in the controller and the executed commands on the controller impacts the
x
network status.
Keywords: Software Defined Networking, SDN, Network Functions Virtualization, NFV,
Sumário
Resumo vii
Abstract ix
Lista de Figuras xiv
1 Introdução 1
1.1 Motivação . . . 1
1.2 Objetivos . . . 2
1.3 Organização do Texto . . . 2
2 Redes Definidas por Software 4 2.1 O que são Redes Definidas por Software . . . 4
2.2 O Controlador SDN . . . 6 2.3 Motivação . . . 10 2.4 O que é NFV . . . 12 2.5 NFV vs SDN . . . 14 2.6 O que é Openflow . . . 15 2.7 Componentes do Openflow . . . 17 2.7.1 Switch . . . 17 2.7.2 Controlador . . . 18 2.7.3 Portas . . . 18
2.7.4 Canal de Comunicação Seguro . . . 19
2.7.5 Tabela de Fluxos . . . 19
3 Principais Soluções de Mercado para Redes Definidas por Software 21 3.1 OpenDaylight open-source SDN controller . . . 22
xii
3.2 Floodlight open SDN controller . . . 22
3.3 Ryu OpenFlow controller . . . 23
3.4 Open Network Operating System . . . 23
3.5 Comparativo entre os controladores SDN . . . 23
4 Exemplo de Uso de um Controlador SDN 25 4.1 Softwares Utilizados . . . 25
4.1.1 ONOS . . . 25
4.1.2 Virtualbox . . . 26
4.1.3 Mininet . . . 27
4.2 Demonstração ONOS e Mininet . . . 28
4.2.1 Demonstração do funcionamento . . . 28
4.2.2 Retirar link entre swtiches . . . 33
4.2.3 Retirar um host do controlador . . . . 36
5 Conclusão 41 5.1 Trabalhos Futuros . . . 41
Lista de Figuras
2.1 Ilustração da Arquitetura SDN e do Modelo OSI. . . 5
2.2 Mudança de fluxo com SDN através de um comando enviado pelo controlador. 6 2.3 Modelo geral de uma arquitetura SDN. . . 7
2.4 Anatomia geral de um Controlador SDN. . . 8
2.5 Fluxos North/South e East/West no contexto de redes de computadores. . 9
2.6 Exemplo das Interfaces NorthBound e Southbound. . . 10
2.7 Linha do Tempo da Migração das funcionalidades para Hardware. . . . 11
2.8 SDN + NFV. . . 14
2.9 Componentes Openflow. . . 17
2.10 Entradas da Tabela de Fluxo Openflow. . . 20
3.1 Informações Técnicas dos Controladores Open Source. . . 24
3.2 Suporte de Casos de Uso dos Controladores Open Source. . . 24
4.1 Arquitetura do Sistema Operacional ONOS. Fonte [4]. . . 26
4.2 Exemplo de criação da Máquina Virtual disponibilizada pela comunidade do ONOS no VirtualBox. . . 27
4.3 Script de Criação da Topologia que será usada na Demonstração. . . 28
4.4 Interface Web ONOS sem dispositivos. . . 29
4.5 Adicionando dispositivos de Rede no Mininet. . . 29
4.6 Interface Web ONOS com dispositivos adicionados. . . 30
4.7 Interface de Comando ONOS mostrando switches da Rede. . . . 30
4.8 Interface de Comando ONOS mostrando Links da Rede. . . 31
4.9 Erro ao tentar comunicação entre hosts. . . 32
4.10 Comunicação entre hosts funcionando. . . . 33
4.11 Topologia de Rede antes da Operação de remover links. . . 34
xiv
4.12 Comandos executados para derrubar links entre os switches na interface de comando do Mininet. . . 34 4.13 Topologia de rede após Operação de remover links. . . 35 4.14 Tráfego de rede na Interface Web Onos. . . 36 4.15 Topologia da rede da interface web do ONOS com o host de IP 10.0.0.24. . 37 4.16 Lista de hosts na interface de linhas de comando do ONOS com o host de
IP 10.0.0.24. . . 38 4.17 Comando para remoção do host da administração do controlador. . . . 38 4.18 Lista de hosts sem o host de IP 10.0.0.24. . . . 39 4.19 Topologia da rede da interface web do ONOS sem o host de IP 10.0.0.24. . 39
Capítulo 1
Introdução
1.1
Motivação
É inegável que as redes de computadores vêm sendo utilizadas em grande escala durantes últimos anos, basta ver que a maioria das atividades da sociedade de hoje de-pendem de uma rede, seja ela Internet, televisão ou telefones. A tecnologia se encontra em todos os lugares, sejam em empresas, governos ou domicílios. Hoje em dia a Inter-net representa não só uma rede, mas também uma forma de inclusão social para alguns governos, e tais governos investem cada vez mais no crescimento da rede mundial de computadores.
A utilização em grande escalada da Internet também traz um grande problema para a comunidade de pesquisa. Como grande parte da estrutura social atual está dependente da Internet, atualizar e promover novas pesquisas se tornou praticamente impossível, pois em casos de erro o impacto na atividades da sociedade podem ser muito grandes. A Internet cresceu muito sobre uma estrutura que não aceita inserção de novas tecnologias e alterações do hardware.
Esses problemas levaram a crer que a arquitetura de redes mundial atíngiu um nível de crescimento e importância que não permite mais flexibilidade.
A comunidade de redes de computadores tem investido em iniciativas que tenham como foco a implementação de redes com maiores recursos de programação para tentar contornar o problema do crescimento e flexibilidade da Internet. Uma das soluções que nasceram dessa idéia foi o protocolo Openflow[16].
Com o Openflow, os dispositivos de rede responsáveis pelo encaminhamento
2
nibilizam uma interface de programação simples que lhes permite acesso a tabela de fluxos do hardware para escolher o próximo passo de cada pacote recebido. Sendo assim, não haverá perda de eficiência no envio de pacotes, pois a consulta à tabela de fluxos continua sendo papel do hardware, porém a decisão sobre o processamento dos pacotes ficará num nível superior, abrindo mais oportunidades para implantação de novas funcionalidades. Essa estrutura abriu caminho para que a rede seja controlada por aplicações em software, com isso temos o surgimento do nome Redes Definidas por Software ou Software Defined
Networking (SDN).
Grandes empresas que possuem redes com grande complexibilidade e dependem de automação de funções da rede adotaram SDN. Com uma oportunidade de um mercado ascendente em vista, grandes companhias como Cisco, VWware, Huawei [14] [17] e outras gigantes que comandam o mercado de redes, passaram a comercializar dispositivos que suportassem o Openflow e apoiar a comunidade de desenvolvedores SDN, o que fortaleceu ainda mais a adoção das Redes Definidas por Software.
1.2
Objetivos
Este trabalho tem por objetivo aprender a utilizar um controlador SDN, mons-trando algumas operações básicas em um ambiente de redes virtuais simuladas. E também mostrar algumas soluções utilizadas no mercado.
Para atingir o objetivo citado, será necessário estudar os conceitos e definições das Redes Definidas por Software (SDN). Além disso, também visa entender como o método de Virtualização das Funções de Rede (NFV) ajuda no funcionamento da arquitetura de Redes Definidas por Software. E ainda explorar a estrutura do protocolo Openflow e en-tender como esse protocolo foi desenvolvido para aen-tender as necessidades de padrinização dos dispositivos de Rede.
1.3
Organização do Texto
O restante do trabalho é organizado da seguinte forma. Os aspectos das Redes Definidas por Software e tecnologias auxilares como Virtualização das Funções de Redes e o protocolo Openflow são discutidos no Capítulo 2. O Capítulo 3 apresenta algumas ferramentas SDN utilizadas no mercado. O Capítulo 4 descreve os experimentos utilizando
3
um controlador SDN em um ambiente de redes virtuais. Finalmente o Capítulo 5 conclui o trabalho e mostra direções para trabalhos futuros.
Capítulo 2
Redes Definidas por Software
2.1
O que são Redes Definidas por Software
A arquitetura de Redes Definidas por Software (SDN) surgiu para facilitar a ino-vação e não comprometer os serviços de redes em produção. Software Defined Networking permitem uma separação útil entre o controle e os dados, essa separação torna possível haver switches e roteadores encaminhando dados de acordo com as regras definidas no plano de controle. O resultado é que o plano de controle da rede fica a disposição dos pesquisadores, que agora podem aplicar novas ideias sem violar as regras de roteamento existentes.
A grande contribuição da arquitetura SDN é possibilitar a rápida configuração da rede conforme a demanda de serviços e negócios das empresas, além de permitir a criação de funções e protocolos, independente do fabricante. [?].
A característica principal da arquitetura das Redes Definidas por Software é a separação da camada de dados e da camada de controle por meio de uma camada de
software que oculta toda a topologia das aplicações. Com isso fica muito mais fácil o
gerenciamento e a configuração da rede, diminuindo a necessidade de dispositivos de rede rebuscados como roteadores e switches. A figura 2.1 mostra os dos modelos SDN e OSI, trazendo uma comparação e a afirmação que SDN também tem uma arquitetura modelo a ser seguida.
5
Figura 2.1: Ilustração da Arquitetura SDN e do Modelo OSI.
É importante definirmos os termos: plano de controle, plano de dados e plano de administração. O plano de dados permite mover dados de um lugar para o outro, como uma rodovia, e não toma decisões por quais rotas os dados devem fluir. Para ajudar a tomar essas decisões existe o plano de controle. Esse plano ajuda a tomar todas as decisões táticas e logísiticas, por exemplo, para onde o pacote de dados deve ir. O plano de administração ajuda a administrar todos esses elementos através de comandos de alto nível que serão traduzidos para os outros planos. Exemplos de interfaces do plano de administração são: consoles, comandos SSH e Web GUIs.
Pode-se dizer que, a arquitetura SDN, dentro de cenários de redes complexas, é uma ótima solução para melhor administração e gerenciamento da rede. Outro grande ponto positivo do uso de um controlador SDN, seria a automação de configurações e do monitoramento de erros, otimizando processos importantes para os times de engenheiros de rede. Por exemplo, por algum problema, um nó da rede passar a ser um gargalo, impe-dindo que o fluxo de informações seja concluído. Nesse caso, bastaria o controlador SDN enviar uma configuração para a rede mudando o seu fluxo automaticamente, conforme é
6
mostrado na figura 2.2.
Figura 2.2: Mudança de fluxo com SDN através de um comando enviado pelo controlador.
Dessa forma, a arquitetura SDN busca simplificar as operações de uma rede. Sendo assim, a ideia é que deve ser possível programar uma rede como se fosse um computador. Isso permite a personalização da rede para atender às necessidades específicas de uma organização.
A arquitetura SDN traz diversos benefícios, tanto para as organizações quanto para os engenheiros de rede, quando implementada de forma correta. Conforme explicado, os benefícios da automação do monitoramento e da simplicidade da gerência de uma rede com um controlador SDN são de grande valia. Logo, realizar uma análise dentre os problemas e prioridades de uma organização e avaliar a possibilidade da implantação da arquitetura de Redes Definidas por Software pode ser um grande diferencial para as empresas [21].
2.2
O Controlador SDN
O controlador SDN é um mediador que permite gerenciamento e automação de funções na rede. Isto é, o controlador pode ver tudo que acontece na rede e automatizar algumas tarefas em dadas circunstâncias. Por exemplo, um controlador SDN permite traduzir comandos em alto nível para comandos de máquina.
7
controla todos os dispositivos SDN que compõem a infraestrutura da rede e dá acesso a uma Api Northbound (esse termo será explicado mais a frente) para aplicações. Então o controlador implementa políticas referentes a roteamento, redirecionamento entre outros. Controladores SDN geralmente têm seu próprio conjunto de módulos de aplicação como roteamento, um firewall básico ou um simples load balancer. [22].
A figura 2.3 mostra um modelo geral de um controlador SDN.
Figura 2.3: Modelo geral de uma arquitetura SDN.
Pode-se dizer que o controlador SDN é o maestro em uma arquitetura de Redes Definidas por Software. Neste contexto, fica claro que o objetivo principal do controlador é administrar o fluxo de dados na rede. É através desse dispositivo que toda comunicação entre a interface da aplicação e os dispositivos da rede são realizadas. Na figura 2.4 é possível ver os componentes que formam um controlador de Redes Definidas por Software.
8
Figura 2.4: Anatomia geral de um Controlador SDN.
Para continuar é preciso definir algumas terminologias utilizadas no contexto de controladores SDN. Os controladores SDN possuem APIs chamadas de Northbound e Southbound. Esses termos estão relacionados a perspectiva do controlador ao plano de controle e não devem ser confundidos com os termos fluxos de tráfego East/West e North/South que estão relacionados a direção dos fluxos: East/West quando os dispo-sitivos se comunicam de Servidor para Servidor e North/South quando os dispodispo-sitivos se comunicam de Cliente para Servidor, conforme mostra a figura 2.5.
9
Figura 2.5: Fluxos North/South e East/West no contexto de redes de computadores.
Com estas ideias em mente, é possível definir Northbound APIs como a interface utilizada pelo usuário ou aplicação para administrar o ambiente de rede SDN. A maioria das soluções SDN desenvolvem suas próprias interfaces, como a VMware vsphere web Client. As Southbound APIs são empregadas na gestão dispositivos de rede [17]. São utilizados protocolos para a comunicação com os componentes da rede e podem ser pa-dronizados, como é o caso do Openflow, ou proprietários como é o caso do Cisco’s onePK API [17]. A figura 2.6 mostra uma exemplo das Apis Northbound e Southbound.
10
Figura 2.6: Exemplo das Interfaces NorthBound e Southbound.
O controlador SDN é utilizado para orquestrar toda rede SDN através de uma interface no lado Northbound que geralmente é disponibilizada pelos fabricantes. Através dessa interface os usuários conseguem programar e atuar sobre toda a rede SDN, pois através da Southbound API é possível se comunicar com qualquer dispositivo da rede que suporte os protocolos que são suportados pelo controlador. Então tarefas como a alteração do fluxo de rede para acertar um gargalo no fluxo de dados, podem ser tanto automatizadas como corrigidas através das interfaces Northbound do controlador.
2.3
Motivação
Um dos problemas frequentes em redes de computadores é que quanto maior o número de nós da rede, maior sua complexidade. Mesmo em redes pequenas ainda falta visibilidade e controle sobre seus dispositivos. Outro grande problema é a escalabilidade, muitas vezes, não é possível saber o impacto que a adição de um novo elemento na rede pode ter. Para resolver esse problema, criar uma central de comando e controle é uma boa opção. Porém, ter uma central não resolveria todos os problemas, pois a rede ainda
11
seria composta de vários dispositivos de empresas diferentes, que possuem sua própria linguagem de comandos. Assim também seria necessário um tradutor. Uma das melhores opções para resolver esses problemas é a adoção da arquitetura SDN, pois o controlador SDN faria o papel de central e tradutor.
Figura 2.7: Linha do Tempo da Migração das funcionalidades para Hardware.
Um dos principais objetivos do SDN é a simplificação. Com o passar do tempo os dispositivos de redes têm se tornado cada vez mais complexos, como mostra a figura 2.7. Isso se dá pelo número de funções que passaram a ser tratadas no hardware, tornando mais díficil a utilização desses dispositivos.[22]
Um dos fatores que aumenta em conformidade com a rede e sua complexidade é o custo de manutenção operacional, ou OPEX [18]. SDN tem a capacidade de acelerar a automação das tarefas de administração em um ambiente com dispositivos de fabricantes diferentes. Outro fator que o SDN permite é o provisionamento rápido de novos serviços. Tais funcionalidades podem diminuir os custos operacionais e até mesmo os custos com a aquisição de novos dispositivos.
As necessidades de armazenamento e velocidade dos data centers extrapolaram as capacidades das redes tradicionais. O avanço tecnológico trouxe novas exigências para o ambiente de data center, e a arquitutura de redes definidas por software pode auxiliar na sua otimização, trazendo mais automação, escalabilidade, multipathing e virtualização de redes [21].
moti-12
vadores para o uso de SDN. E ainda as necessidades de um data center interconectado e bem monitarado também podem somar para difusão da tecnologia SDN.
2.4
O que é NFV
Network Functions Virtualization (NFV) é uma tecnologia em constante
cresci-mento e que vem influenciando fortemente o mundo das redes de computadores. Essa tecnologia traz com elas novas formas de como as redes são gerenciadas, projetadas e pro-visionadas. A indústria de redes de computadores passa a ter um maior foco e virtualiza-ção, indo em direção contrária a hardware customizados com configurações padronizadas de software[22].
NFV é sobre criação de serviços e componentes para rede. O NFV descreve e define como os serviços da rede são projetados, construídos e instalados usando componentes de
softwares virtuais e como essas aplicações são desacopladas do hardware que as executa.
Também permite a orquestração de serviços ou componentes virtualizados, junto com seu
hardware físico. Isso significa, criação, destruição, alteração e interconexão desses serviços
ou componentes[19].
Nos data centers, a virtualização de servidores é uma tecnologia testada e aprovada,
racks de servidores foram substituídos por servidores virtuais que rodam em hardware
compartilhados. NFV é embasado em um conceito além de virtualização de servidores, incluindo também os funções de rede. E também permite a criação de um ambiente para gerenciar, provisionar e monitorar os dispositivos de rede virtualizados.
Então, o uso do método NFV vai muito além de virtualizar um servidor e podemos virtualizar toda a rede de uma organização e seus serviços. Isso facilita todo o processo de provisionamento e gerência de dispositivos de rede, uma vez não há necessidade de se utilizar um hardware específico para cada função na rede, podendo utilizar hardware genéricos para essas funcões.
No fundo, NFV é sobre criação de serviços e funções. O verdadeiro valor deste método consiste nas fases iniciais do projeto de rede que pode ser combinado com outras arquiteturas, como o SDN.
A implementação do método NFV é bastante válida para organizações que possuem redes de computadores físicas. Várias vantagens são adquiridas com a implementação da
13
tecnologia NFV, por exemplo, substituir um appliance de firewall físico por um máquina virtual baseada em software. Essa máquina virtual terá as funções de firewall e rodará em um hardware não dedicado, genérico e compartilhado.
Sendo assim, a virtualização de redes abre novas possibilidades de como a rede pode ser instalada e gerenciada. A flexibilidade, agilidade, escalabilidade e economia com custos e operacional que o NFV torna possível, abre caminho para inoções, novos paradigmas e novas arquiteturas de rede.
Fica claro que a metodologia do NFV traz várias inovações, e com isso, novos desafios a serem vencidos. E o uso dessa tecnologia se torna ainda mais vantajoso quando alinhada com outras inovações, como SDN.
14
2.5
NFV vs SDN
A ideia do NFV é mover as funcionalidades do serviços, firewalls, balanceadores de carga e etc, de dispositivos físicos especializados e implementa-os em um software que roda em hardware comuns. E isso é possível graças a evolução da tecnologia das interfaces de serviços e redes. Aplicações que antes necessitavam de um hardware específico para rodar, agora podem funcionar em hardwares genéricos. Alguns pontos que fortalecem essa ideia são a redução de custos conforme a necessidade de novos servidores e a facildade de atualizar noshardwares genéricos quando necessário.
NFV é o próximo passo da virtualização, transformando equipamentos de redes fí-sicos em softwares que rodam em uma máquina virtual. É possível simular qualquer tipo de equipamento em uma máquina virtual, sejam eles switches, roteadores, load balancers, configuração de anti vírus e até mesmo IPS e IDS (Intrusion Protection/ Detection
Sys-tem). Equanto NFV está relacionado a provisionamento de novos dispositivos de rede o
SDN está ligado a automação e gereciamento dos elementos da rede, sejam eles físicos ou virtuais [17]. A figura 2.8 demonstra a relação entre as tecnologias SDN e NFV.
Figura 2.8: SDN + NFV.
O papel da arquitetura SDN na rede está ligado ao gerenciamento e automação dos dispositivos. O NFV vai funcionar dentro da rede de acordo com um conceito simples, a
15
rede terá um controlador NFV e um hypervisor. A partir daí basta solicitar um dispositivo ou serviço de rede novo, conforme a necessidade. Por exemplo, se a rede necessita de um
firewall, o controlador NFV vai disponibilizar uma máquina virtual que fará o papel de
um firewall. E todos esses dispositivos poderão ou não ser gerenciados pelo controlador SDN.
2.6
O que é Openflow
É praticamente impossível para um dispositivo de rede conhecer todos os comando dos sistemas operacionais de todos componentes de rede dos fabricantes existentes, até mesmo uma única empresa pode ter vários sistemas operacioanais com a sintaxe dos comandos diferentes. Então é necessário uma padronização na comunicação entre esses dispositivos.
OpenFlow é um protocolo de comunicação que roda entre o plano e controle e o plano de dados, permitindo ao plano controle especificar o comportamento do plano de dados.
Neste contexto, fica claro que foi necessária a criação desse protocolo para o sucesso da arquitetura SDN. Não é exagero afirmar que a aceitação dos grandes fabricantes de dispositivos de rede foi fundamental em todo esse processo. Assim, hoje grande parte dos dispositivos de rede pode se comunicar, independente do fabricante, com um controlador central na rede.
Em sua essencia, esse protocolo consiste um conjunto de mensagens que são envia-das de um controlador para um switch e um conjunto de mensagens que são enviaenvia-das na direção oposta. As mensagens permitem o controlador programar o switch e também rea-lizar um ajuste fino no controle do tráfego do usuário. As funções básicas da programação são definidas por modificar e apagar fluxos de rede [21].
O OpenFlow define:
• Um conjunto de instruções de fluxo que engloba o comportamento do dispositivo de rede
• Um conjunto de mensagens que cada dispositivo de rede pode enviar para o controlador SDN
16
• Um protocolo para enviar e receber as mensagens entre o controlador e o dispo-sitivo
E em uma visão de mais alto nível, o OpenFlow consiste nos seguintes componentes:
• Um controlador
• A interface OpenFlow no switch
• Um canal de comunicação seguro entre o controlador e o switch • Uma tabela de fluxo que contém as instruções dos caminhos da rede
É importante dizer que o OpenFlow não é a única solução para o problema de padronização na comunicação entre os dispositivos de rede, porém é a mais indicada [21]. Pois além de uma forte comunidade que contribui com seu desenvolvimento, muitas das principais empresas no ramo das redes de computadores dão suporte a essa tecnologia.
Logo, existe uma definição clara do que é o OpenFlow, mas existem algumas con-fusões em relação a esse conceito.
• OpenFlow não especifica um controlador ou um swtich. Apenas especifica os meios pelos quais esses dispositivos se comunicam e o que é comunicado.
• OpenFlow não é executado em nenhum outro plano a não ser o plano de controle e o plano de dados.
• OpenFlow não é utilizado para criar redes ou elementos da rede. É usado para controlar o comportamento do plano de dados.
• OpenFlow não é o único meio de comunicação entre o plano de controle e o plano de dados. Alternativo a essa tecnologia, existem alguns protocolos como: NETCONFIG, Extensible Message and Presence Protocol (XMPP), BGP, Open vSwitch Database Management Protocol (OVSDB), Cisco’s onePK e outros.
Então, o procolo OpenFlow é fundamental para haver comunicação entre o con-trolador e a rede na arquitetura SDN. E apesar de existirem outras soluções, essa tec-nologia amparada por uma forte comunidade de desenvolvedores e as grandes empresas do mercado de redes de computadores. É preciso também entender bem as definições do protocolo e sua função em uma rede que utiliza a tecnologia SDN.
17
2.7
Componentes do Openflow
O protocolo Openflow é composto por alguns componentes fundamentais para o seu funcionamento. Esses componentes são: o controlador, o switch, que é o termo utilizado para os componentes de rede, que contém: portas, canal de comunicação seguro e tabela de fluxos. A figura 2.9 demonstra os componentes do Openflow.
Figura 2.9: Componentes Openflow.
2.7.1
Switch
Switch é um termo utilizado para os componentes da rede que têm uma função
lógica. É nesses disposivos onde o Openflow tem mais destaque. O processamento de pacotes acontece através de um conjuntos de tabelas: tabelas de fluxo, tabelas de frupo e tabelas de métricas. Essas tabelas são populadas com instruções que vêm do controlador através do canal de comunicação. Pacotes entram e saem pelas portas, assim como em dispositivos normais.
18
Um switch pode ser um switch somente Openflow ou híbrido. Switches somente Openflow, como o próprio nome sugere, só conseguem processar e enviar pacotes usando os componentes descritos no protocolo. Já Switches híbridos suportam tanto o Openflow como a comunicação de rede tradicional.
2.7.2
Controlador
Embora o controlador seja um componente fundamental na arquitetura SDN, para o contexto do Openflow este item é apenas um periférico. Praticamente tudo que é interessante para o funcionamento do método Openflow acontece sob o controlador.
O componente Openflow no controlador tem a missão de comunicar as instruções para o Switch através de um canal de comunicação seguro, mas o protocolo Openflow não tem conhecimento de como o controlador determina quais instruções enviar. Toda essa lógica acontece em uma camada dentro ou superior ao controlador. Essas instruções são determinadas por uma configuração automática do componente, por uma intervenção direta de um operador da rede ou por protocolos como OSPF(Open Shortest Path First) e BGP (Border Gateway Protocol), que são protocolos de roteamento.
O controlador também pode utilizar outros protocolos alternativos ao Openflow, isso pode ocorrer para se comunicar com outros componentes da rede que utilizam outros protocolos abertos ou proprietários.
2.7.3
Portas
Portas em dispositivos Openflow servem para o mesmo propósito que em switches tradicionais, entrada e saída. Pacotes são recebidos em uma porta de entrada, processados e enviados por uma porta de saída. Se a porta é de entrada ou saída, isso é definido de acordo com a perspectiva do fluxo do pacote, a porta de entrada para um fluxo pode ser a porta de saída para outro fluxo.
Uma porta pode ser adicionada, alterada ou removida da configuração do switch utilizando, por exemplo, OF-CONFIG (conjunto especial de regras que definem um me-canismo para os controladores Openflow modificarem e acessarem os switches [16]) ou diretamente pelo controlador. O estado da porta também pode ser alterado, por exem-plo, quando o link fica fora de uso ou em uso. A alteração de uma porta não muda a tabela de fluxos. Se, por exemplo, uma porta fica fora de uso ou é removida e pacotes são
19
enviados para essa porta pela tabela de fluxo, esses pacotes são perdidos. Por essa razão, toda mudança na configuração das portas deve ser comunicada ao controlador para que ele possa atualizar os fluxos relacionados à porta alterada.
O Openflow define três tipos de portas, e todo switch Openflow deve suportá-las: portas físicas, lógicas e reservadas.
Portas físicas correspondem as interfaces do hardware em um switch.
Portas lógicas não correspondem diretamente as interfaces de hardware físico. O processamento dos pacotes nas portas lógicas, como encapsulamento e desencapsulamento, é uma implementação específica e independente do Openflow. Da perspectiva dos proces-sos Openflow, as portas lógicas são tratadas exatamente como as portas físicas.
Portas reservadas são utlizadas para processamento interno dos pacotes, para fun-ções específicas como flooding ou, inundação, ou em um switch híbrido, na mudança do processamento de fluxo Openflow para o processamento tradicional.
2.7.4
Canal de Comunicação Seguro
As conexões Openflow utilizam TCP, e tanto o switch quanto o controlador ouvem na porta 6653. O switch começa a conexão com o controlador assim que inciado, enviando tráfego para a porta padrão 6653 ou a porta definida pela configuração. Existe a opção de deixar o controlador iniciar a conexão. A conexão pode operar sem nenhuma configuração de segurança mas usualmente é encapsulada em TLS (Transport Layer Security). É uma recomendação de segurança sempre utilizar o TLS. Imediatamente após a sessão TCP ser estabelecida e certificada pelo TLS, o controlador e o switch trocam mensagens para negociar qual versão do Openflow será utilizada. Normalmente a versão utilizada será a versão mais atual que ambos os lados suportam. A partir de agora o controlador e o
switch podem se comunicar. A comunicação entre esses dispositivos é monitorada através
de um sistema de Request/ Reply para saber o estado e a latência da conexão.
2.7.5
Tabela de Fluxos
A tabela de fluxos do Openflow é um conjunto sequencial de instruções com vários campos e ações a serem tomadas. Essa tabela consiste em um conjunto de entradas de fluxos como ilustrado na Figura 2.10:
20
Figura 2.10: Entradas da Tabela de Fluxo Openflow.
• Match Field: verifica se a entrada é aplicável ao pacote analisado. • Priority: define a precedência do fluxo.
• Counter : grava estatísticas dos pacotes corretos.
• Instruction: Especifica as ações que devem ser tomadas nos pacotes. • Timeouts: específica o tempo de timeout do pacote.
• Cookie: usado pelo controlador para filtrar entradas de fluxo na tabela. Esse campo é oculto para o switch.
• Flag: usado para alterar o jeito como o fluxo é administrado.
É importante ressaltar a diferença entre a tabela de fluxos do Openflow e tabela de fluxo tradicional, pois switches Openflow híbridos podem utilizar ambas as tabelas. As tabelas de fluxo tradicionais são apenas conjuntos de instruções mapeadas, com endereço de uma porta específica. E as tabelas de fluxo são conjuntos sequenciais de instruções com vários campos e ações a serem tomadas.
Capítulo 3
Principais Soluções de Mercado para
Redes Definidas por Software
Quando se fala em adotar uma tecnologia de Redes Definidas por Software, alguns problemas podem vir à tona. Um grande problema enfrentado pelo mercado SDN é a constante mudança dos produtos e distribuidores. Outro problema é que SDN passou a ser um nome utilizado pelo Market das empresas para vender produtos, o que torna a pesquisa para adoção de um bom produto um pouco mais desafiadora. E com a mudança rápida da indústria de Redes Definidas por Software, a pesquisa para adoção de uma tecnologia tem de ser rápida, pois se, por exemplo, uma empresa passa um ano pesquisando uma solução, o mercado pode ter mudado tão dramaticamente que a pesquisa estará desatualizada.
A arquitetura SDN foi desenvolvida em 2008, e o número de empresas desse mer-cado foi crescendo muito durante os últimos anos. A compra de algumas dessas empresas por empresas maiores e até a mesmo junção de empresas e produtos mudam o cenário do mercado SDN constantemente. Com isso, novos produtos estão sendo desenvolvidos e lançados a cada dia. O problema é que alguns desses produtos seguem os princípios do SDN e outros tentam inventar um novo conceito para essa tecnologia.
Para começar a implantação da arquitetura SDN, umas das coisas mais recomen-dadas é utilizar uma solução Open Source [17]. Não somente porque são solução gratuitas, mas porque esses produtos permitem seguir o caminho que a comunidade de desenvol-vedores está tomando. Utilizar uma solução Open Source tem lados positivos como o suporte de vários desenvolvedores da comunidade, porém um lado negativo é o tempo investido para aprender sobre cada iniciativa.
22
Na próxima seção, algumas das principais iniciativas Open Source do mercado SDN [1] serão listadas e uma dessas soluções será utilizada para demonstração do uso de um controlador no Capítulo 4.
3.1
OpenDaylight open-source SDN controller
O OpenDaylight ou ODL foi fundado em 2013. A missão dessa fundação é facilitar o crescimento do ODL e das tecnologias SDN colaborando com os desenvolvedores, usuá-rios e membros da comunidade para produzir aplicações, eventos e recursos relevantes [9].
O OpenDaylight foi criado para suportar redes de qualquer tamanho e escala. O ODL permite serviços de redes entre hardwares de ambientes com dispositivos de vários vendors diferentes. É baseado em uma arquitetura de microserviços que permite aos usuários o controle por aplicações, protocolos e plugins. A modularidade e flexibilidade do OpenDaylight permite aos seus usuários selecionar a função que mais importa para e criar um controlador que supra suas necessidades.
Esse sistema conta com uma comunidade de desenvolvedores muito grande e apoi-ada por várias iniciativas. Conta também com uma WIKI que guia os interessados desde a instalação da plataforma até o desenvolvimento de novas funcionalidades [5].
3.2
Floodlight open SDN controller
O Floodlight Open SDN Controller é um controlador SDN Opensource e usa a lincença do Apache 2.0. Essa plataforma é baseada em JAVA e utiliza o protocolo Open-flow. O Floodlight foi projetado para trabalhar com um grande número de dispositivos de rede, virtuais ou físicos que suportem Openflow. O Floodlight foi pensando para ser simples para se construir e rodar e conta com uma comunidade desenvolvedores aberta. Todo o código do controlador Floodlight é testado frequentemente e melhorado pelo seus desenvolvedores [6].
O controlador Floodlight tem uma vasta Wiki que abrange a instalação da apli-cação, os switches compatíveis, um guia para usuários e um guia para desenvolvedores [2].
23
3.3
Ryu OpenFlow controller
Ryu é um software baseado em componentes de Redes Definidas por Software. A plataforma disponibiliza uma API para tornar o desenvolvimento simples para criar novas aplicações de administração e controle da rede. Suporta vários protocolos para a gerência dos dispositivos de rede, tais como: OpenFlow, Netconf e OF-config [10].
O Ryu possui uma das Wiki mais completas e até mesmo um E-Book que aborda a fundo a estrutura do controlador[12].
O Ryu também tem lincença pela Apache e foi escrito em Phyton [23].
3.4
Open Network Operating System
O controlador Open Network Operating System ou ONOS, será explorado no pró-ximo capítulo, pois foi o controlador escolhido para a demonstração.
3.5
Comparativo entre os controladores SDN
Essa seção tem por objetivo trazer algumas comparações entre os controladores citados anteriormente. Para trazer essas comparações foram contruídas duas tabelas. A primeira contém informação técnicas sobre alguns requisitos técnicos dos controladores, como mostra a Figura 3.1 [20]. A segunda contém informações sobre alguns casos de uso que os controladores suportam, tal fato está retratado na Figura 3.2 [13].
Na figura 3.2 os parâmetros utilizados para cada valor são: Sim:
• Suporta totalmente o caso de uso.
• Existe uma solução comercial desenvolvida utilizando o controlador Open Source. Não:
• Não suporta o caso de uso.
• Não existe uma solução comercial desenvolvida utilizando o controlador Open Source.
24
• Suporta o caso de uso parcialmente. •
• Existe uma solução comercial em desenvolvimento utilizando o controlador Open Source.
Figura 3.1: Informações Técnicas dos Controladores Open Source.
Capítulo 4
Exemplo de Uso de um Controlador
SDN
4.1
Softwares Utilizados
Para demonstrar a utilização de um controlador SDN foram utilizados os seguintes
softwares ou sistemas.
4.1.1
ONOS
ONOS é uma abreviação para Open Network Operating System e é um sistema operacional de Redes Definidas por Software. Esse sistema operacional tem como obje-tivo prover escala, alta disponibilidade, alta performance e abstrações das Northbound e Southbound APIs para facilitar a criação de aplicações e serviços de rede. A plata-forma conta com uma grande comunidade de desenvolvedores bem ativa que estão sempre trazendo novidades e atualizações e mais de 50 parceiros [8].
A plataforma ONOS tem como missão a criação de um sistema operacional Open Source que possibilita serviços para criação de uma arquitetura SDN.
ONOS é um sistema distribuído e roda como um cluster. O Distributed Core administra os estados das instâncias do Sistema Operacional e é a peça chave para fun-cionamento do sistema. O SB Core API permite interação dos dispositivos através do Openflow ou outros protocolos. O NB Core API permite a comunicação com aplica-ções externas para o desenvolvimentos de serviços para melhor controle, administração e configuração. A figura 4.3 ilustra a arquitetura do ONOS.
26
É interessante dizer que o Onos foi construído em vários módulos, e cada módulo é representado por uma camada da arquitetura. Logo para cada elemento da arquitetura, existe um módulo separado do Sistema Operacional para executar as atividades [4].
Figura 4.1: Arquitetura do Sistema Operacional ONOS. Fonte [4].
O ONOS também dispõe de uma interface web muito funcional que facilita a administração e manutenção da rede. Essa interface será explorada na próxima seção para demonstrar o uso do controlador.
4.1.2
Virtualbox
O Virtualbox é um software de virtualização feito para uso tanto empresarial quanto doméstico. O Virtualbox é Open Source e está sob os termos GNU General Public
License (GPL). Essa aplicação pode rodar em ambiente Windows, Linux, Macintosh e
Solaris. E suporta emular diversos sistemas operacionais [11].
Utilizamos o Virtualbox para instalar a imagem que a comunidade de desenvolvi-mento do ONOS nos oferece. Essa imagem já vem com o Mininet e o Onos instalados. Para instalar a imagem basta criar uma máquina virtual e escolher o arquivo de imagem .vmdk, como mostra a Figura 4.1 [15].
27
Figura 4.2: Exemplo de criação da Máquina Virtual disponibilizada pela comunidade do ONOS no VirtualBox.
4.1.3
Mininet
O Mininet é simulador de rede. Com esse software podemos simular uma rede virtual completa com hosts, links, switches em uma única máquina. Um host criado pelo Mininet se comporta com uma máquina real, é possível abrir conexões SSH e até mesmo rodar aplicações que são nativas do Linux. Os programas podem enviar pacotes por uma interface Ethernet simulada de acordo com a banda do link e delay. O Mininet cria máquinas reais, só que utilizam software ao invés de hardware. É possível criar redes físicas inteiras utilizando Mininet [7].
O Mininet possui uma API em python para utilizar seus recursos. Com apenas algumas linhas de código é possível criar uma topologia de rede.
Para a demonstração utilizamos o código mostrado na Figura 4.2 para criar uma topologia com 24 hosts, 6 switches e também os links entre eles. A partir desse código várias topologias de rede podem ser criadas [3]. Este trecho de código foi cedido pela
28
comunidade do ONOS.
Figura 4.3: Script de Criação da Topologia que será usada na Demonstração.
4.2
Demonstração ONOS e Mininet
4.2.1
Demonstração do funcionamento
O objetivo desta seção é mostrar o uso do controlador SDN ONOS em conjunto com o Mininet. Será utilizada uma imagem em uma máquina virtual disponibilizada pela ONOS e instalada com o Virtualbox.
29
de acordo com a interface web.
Figura 4.4: Interface Web ONOS sem dispositivos.
O primeiro passo é criar uma rede virtual com o Mininet rodando na VM com o ONOS e adicionar o controlador à rede. A rede criada contém 24 hosts, 6 switches e também os links conforme a Figura 4.5 abaixo:
30
Após adicionados os dispositivos de rede, podemos vê-los tanto na interface web do ONOS, conforme a Figura 4.6, como na interface de linhas de comando.
Figura 4.6: Interface Web ONOS com dispositivos adicionados.
Para visualizar os switches no controlador, basta executar o comando devices na interface de linhas de comando do ONOS, Figura 4.7.
31
Para visualizar os links, basta executar o comando links na interface de comando do ONOS, Figura 4.8.
Figura 4.8: Interface de Comando ONOS mostrando Links da Rede.
Os dispositivos da rede já estão instalados, mas o módulo que ativo o monito-ramento do tráfego na rede ainda não está disponível. Quando tantamos executar a operação de ping entre dois hosts a interface do Mininet retornará um erro, apotando que não consegue alcançar o dispositivo.
Foi feita uma tentativa de comunição entre os hosts h11 e h45 como mostra a Figura 4.9, e foi retornado o seguinte status: Destination Host Unreachable.
32
Figura 4.9: Erro ao tentar comunicação entre hosts.
Para ativar o fluxo na rede precisamos ativar o módulo fwd, que habilita o en-caminhamento na rede. Para ativar esse módulo basta executar o seguinte comando na interface de comando do ONOS:
onos> app activate org.onosproject.fwd
Após ativar o módulo fwd, repetimos a operação de ping entre os hosts h11 e h45. Dessa vez a comunição entre os hosts foi efetuada com sucesso, retornando que 3 pacotes foram enviados e 3 pacotes recebidos em um tempo total de 2000 ms e sem perda de pacotes. A Figura 4.10 expõe a situação descrita.
33
Figura 4.10: Comunicação entre hosts funcionando.
Com isso, é verificado que as ações tomadas no controlador são refletidas na rede.
4.2.2
Retirar link entre swtiches
Para reforçar a capacidade de monitoramento de rede do ONOS, a tarefa de re-mover links entre swtiches será executada no Mininet. Com isso, será possível saber se o ONOS também monitora a comunição em tempo real entre os switches.
A tarefa de alterar links de swtiches ainda não foi implementada no controlador ONOS, por isso vamos apenas testar a capacidade da interface Web refletir essa alteração na rede.
34
Figura 4.11: Topologia de Rede antes da Operação de remover links.
O primeio passo é remover os links entre alguns switches com a interface cmd do Mininet. A Figura 4.12 mostra os comandos executados.
Figura 4.12: Comandos executados para derrubar links entre os switches na interface de comando do Mininet.
Após os comandos para derrubar os links, na Figura 4.13, é possível ver que o número de links dimunui para 12 e os traços que ligavam os switches s1-s2, s1-s11 e s1-s12 já não estão mais presentes.
35
Figura 4.13: Topologia de rede após Operação de remover links.
Logo pode-se confirmar que o ONOS é uma ferramenta bastante efetiva no mo-nitoramento em tempo real, ajudando a identificar rapidamente em caso de problemas de conexão e até mesmo outros problemas, como um caminho congestinado. Conforme mostra a Figura 4.14 a interface Web do ONOS também mostra o fluxo de dados entre os switches.
36
Figura 4.14: Tráfego de rede na Interface Web Onos.
4.2.3
Retirar um host do controlador
Após verificar que a integração entre o controlador SDN e a rede virtual está funcionando corretamente, foi feita a tentativa de desabilitar um dos hosts criados pelo Mininet através da interface de comando do controlador ONOS.
Através da Figura 4.15 é possível ver que o host de IP 10.0.0.24 está ativo na rede e o controlador marca que existem 24 hosts ativos, conforme foi criado pelo script do Mininet na seção anterior.
37
Figura 4.15: Topologia da rede da interface web do ONOS com o host de IP 10.0.0.24.
Na Figura 4.16 é ilustrado o ID do host de IP 10.0.0.24, que é listado através do comando hosts na interface de linhas de comando do ONOS.
38
Figura 4.16: Lista de hosts na interface de linhas de comando do ONOS com o host de IP 10.0.0.24.
Com a identificação do host na rede é possível remove-lo da administração do ONOS com o comando mostrado na Figura 4.17.
Figura 4.17: Comando para remoção do host da administração do controlador.
Para confirmar que o host foi mesmo removido a Figura 4.18 apresenta a lista de
hosts, onde o host de IP 10.0.0.24 não faz mais parte e a figura 4.19 que representa a
interface web do ONOS e não exibe mais o host com IP 10.0.0.24 e o número de hosts listados diminuiu para 23 hosts ativos.
39
Figura 4.18: Lista de hosts sem o host de IP 10.0.0.24.
40
Portanto é possível concluir que o controlador pode ter grandes impactos na rede, pois alterações como a remoção de um elemente de rede podem mudar o modo como as informações trafegam. Várias operações podem ser executadas através da interface de comando do ONOS, como a criação de novos fluxos e criação de novos caminhos entre os
Capítulo 5
Conclusão
Esse trabalho teve por objetivo estudar os fundamentos da arquitetura de Redes Definidas por Software ou SDN, da Virtualização das Funções da Rede ou NFV e do funcionamento do protocolo Openflow. Sendo assim, foi concluído que a utilização da arquitetura SDN é regida pelo critério de número de elementos da rede e do retorno sobre o investimento de uma empresa. As diferenças entre NFV e SDN também foram abordadas e esclarecidas.
Um segundo objetivo do trabalho foi demonstrar a utilização de um controlador SDN. Dentre os controladores apresentados, o escolhido foi o controlador ONOS, pela facilidade de implementação e atenção que vem tendo pela comunidade de desenvolve-dores. Foi possível demonstrar a criação de uma rede virtual e monitorá-la pelo ONOS. Os seguintes eventos foram utilizados como testes: a remoção de um host da rede utili-zando o controlador, para testar se as ações tomadas no controlador refletiam na rede, e a remoção de links de switches de rede pela interface do controlador Mininet para testar se as alterações na rede eram monitoradas pelo controlador. Ambos os testes obtiveram sucesso.
5.1
Trabalhos Futuros
O controlador ONOS é uma plataforma Open Source, o que possibilita o desenvol-vimento de novas funcionalidades para a ferramenta. É desejável que possamos controlar os links entre os swtiches pelo próprio controlador ONOS, pois o controlador ainda não consegue realizar essa atividade com os comandos nativos. Outro fato interessante é a
42
de criar um ambiente de testes com a ferramenta simulando um ambiente real e testar se conseguimos refletir todo o ambiente.
Outras considerações importantes a serem testadas são a utilização do controlador em uma rede real de uma corporação, com dispositivos físicos e virtuais. Pretende-se fazer testes utilizando dispositivos reais com compatibilidade ao Openflow e implementar as estratégias propostas pela literatura.
E ainda realizar testes comparando a performance de protocolos tradicionais de administração de redes e a arquitetura de Redes Definidas por Software.
Referências Bibliográficas
[1] Five must-know open source sdn controllers. http://searchsdn.techtarget.com/
news/2240225732/Five-must-know-open-source-SDN-controllers.
[2] Floodlight wiki. http://www.projectfloodlight.org/documentation/.
[3] Mininet wiki.
https://github.com/mininet/mininet/wiki/Introduction-to-Mininet#what.
[4] Onos project wiki. https://wiki.onosproject.org/display/ONOS/Wiki+Home.
[5] Opendaylight wiki. https://wiki.opendaylight.org/view/OpenDaylight_
Controller:Main.
[6] Página oficial do floodlight. http://www.projectfloodlight.org/floodlight/.
[7] Página oficial do mininet. http://mininet.org/.
[8] Página oficial do onos project. http://onosproject.org.
[9] Página oficial do opendaylight. https://www.opendaylight.org/.
[10] Página oficial do ryu. http://osrg.github.io/ryu/.
[11] Página oficial do virtualbox. https://www.virtualbox.org/.
[12] Ryu wiki. http://osrg.github.io/ryu/resources.html#wiki.
[13] Sdn series part eight: Comparison of open source sdn controllers. https:
//thenewstack.io/sdn-series-part-eight-comparison-of-open-source-sdn-controllers/.
44
[14] Top 10 sdn market leaders in the data center and enterprise in 2016.
http://www.crn.com/slide-shows/networking/300079644/top-10-sdn-market-leaders-in-the-data-center-and-enterprise-in-2016.htm.
[15] Virtualbox wiki. https://www.virtualbox.org/wiki/Documentation.
[16] P. Moyer D. Marschke, J. Doyle. Software Defined Networking (SDN): Anatomy of
OpenFlow Volume I. Lulu.com, 1a edition, 2015.
[17] B. Eiler e J. Hales. Software defined networking (sdn): The big picture. https://app.pluralsight.com/library/courses/sdn-big-picture/
table-of-contents, 2014.
[18] T. D. Nadeau e K. Gray. SDN: Software Defined Networks: An Authoritative Review
of Network. O’Reilly, 1a edition, 2013.
[19] T. D. Nadeau K. Gray. Network Function Virtualization. Morgan Kaufmann, 1a
edition, 2016.
[20] A. Kayssi A. Chehab O. Salman, I. H. Elhajj. Sdn controllers: A comparative study. 2016.
[21] T. Culver P. Goransson, C. Black. Software Defined Networks: A Comprehensive
Approach. Morgan Kaufmann, 1a edition, 2016.
[22] P. Shah R. Chayapathi, S. F. Hassan. Network Functions Virtualization (NFV) with
a Touch of SDN. Addison-Wesley Professional, 1a edition, 2016.
