Redes Programáveis - Aula 2

Prévia do material em texto

Redes De�nidas por Software
Aula 01: Problemas das Redes Atuais e Origem da Proposta
SDN
Apresentação
Redes De�nidas por Software (SDNs) são indiscutivelmente uma das mais signi�cativas mudanças de paradigma que a
indústria de redes tem visto nos últimos anos. A SDN foi impulsionada pela necessidade de acompanhar os novos
requisitos de rede a partir de tendências emergentes de aplicativos virtualizados em nuvem, computação, mobilidade e Big
Data.
 
Os objetivos da SDN incluem a capacidade de introduzir inovações de rede mais rapidamente e simpli�car e automatizar
de maneira radical o gerenciamento de grandes redes.
 
Nesta aula, apresentaremos os problemas e/ou as atuais necessidades presentes em Redes de Computadores, que
impulsionam/impulsionaram a criação desse novo paradigma.
Objetivos
Identi�car os problemas nas redes atuais que impulsionaram a proposta SDN;
Apontar os principais componentes de uma SDN;
Listar possíveis aplicações para a SDN.
 Premissa
Vivemos em uma época em que a tecnologia de Redes de Computadores está presente em todos os níveis da sociedade.
A maioria das atividades do nosso dia a dia, de alguma forma, usa serviços oferecidos por uma ou mais Redes de
Computadores.
Temos a Internet presente nos lares, nas rotinas de implementação de serviços públicos, na educação etc. Ou seja, ela se
tornou uma das fontes essenciais de informação em diversos níveis da sociedade, podendo ser vista como uma espécie
de “artefato” que é conhecido e pode ser acessado por uma fração signi�cativa da população (GUEDES et al., 2012).
Contudo, esse grande sucesso causa problemas tanto para a economia quanto para a área de pesquisa e avanços
tecnológicos. Hoje em dia, grande parte da sociedade depende da Internet para todo tipo de atividade, no trabalho ou em
quaisquer outras tarefas diárias. Seu uso constante se deve principalmente às tecnologias de acesso à rede (em principal
celulares), que praticamente impõem uma característica essencial para a Internet nos dias atuais: a estabilidade.
Atenção
Isso signi�ca que atividades que possam levar ao risco de uma interrupção no seu funcionamento (tais como testes de
novas tecnologias, pesquisas que envolvam novos protocolos) sejam impedidas de serem testadas na própria Internet. Esse
risco de se interromperem atividades para as quais a Internet já se tornou ferramenta essencial praticamente inibe a
possibilidade de parar de funcionar.
Exemplo
Por exemplo, a troca de um tipo de protocolo pode representar a parada momentânea de algum serviço, tal como a venda de
um produto. Nesse caso, essa parada, mesmo que por um momento, implicaria grande prejuízo para a empresa vendedora.
Isso não apenas se aplica a tentativas de testes de novos protocolos (Softwares), mas também inviabiliza a inserção de
novas tecnologias que dependam de alterações no Hardware (equipamento) já utilizado e em uso contínuo.
Tal característica levou diversos pesquisadores a afirmarem que a arquitetura de Redes de Computadores, em geral, e a rede mundial (a
Internet) atingiram um nível de amadurecimento que a tornou pouco flexível. Uma expressão que passou a ser utilizada e que indica tal
situação é que “a Internet está ossificada” (ossified, em inglês). Esse termo significa que ela se encontra em uma condição que a torna
rígida, ou seja, contrária a mudanças. Na tentativa de contornar esse problema, a comunidade de pesquisa em Redes de Computadores
tem investido em inciativas que levem à implantação de redes com recursos de programação, de forma que novas tecnologias possam
ser inseridas de maneira gradual. Exemplos de iniciativas desse tipo são as propostas dos chamados testbeds, que podem ser
entendidos literalmente como um “ambiente de testes” em grande escala. O objetivo dos testbeds é permitir experimentar determinada
ideia em um ambiente controlado. Iniciativas mais recentes apostam na adoção de recursos de virtualização a fim de facilitar a transição
para novas tecnologias. Ou seja, muitas empresas utilizam esse artifício para compartilhar os recursos das máquinas físicas em diversos
servidores diferentes. Com o avanço dessa tecnologia de virtualização, além de ela ser usada em servidores, também se pode fazer a
virtualização de redes, usando máquinas virtuais como elementos de redes (LOBATO et al., 2013). Apesar de serem consideradas de
grande potencial em longo prazo, tais iniciativas (tanto testbeds quanto virtualização) ainda enfrentam desafios em como garantir o
desempenho exigido pelas aplicações largamente empregadas hoje em dia (GUEDES et al., 2012), visto que algumas operações exigem
alto desempenho. Uma das operações que mais necessita desse alto desempenho nas Redes de Computadores atuais é o
encaminhamento de pacotes. Assim, algumas iniciativas propõem conservar essa operação pouco alterada, para manter a viabilidade de
desenvolvimento de hardware de alto desempenho, mas com uma possibilidade de maior controle por parte do administrador da rede.
Essa proposta foi inspirada em uma tecnologia já largamente adotada, o chaveamento (encaminhamento) baseado em rótulos
programáveis, popularizado pelo MPLS (do inglês, Multi-protocol Label Switching). O MPLS possibilita o controle de tráfego atribuindo
um label (rótulo) a cada pacote. Esse rótulo determinará como um equipamento intermediário tratará do pacote em questão. Com esse
recurso, é possível realizar diversas ações, entre elas, o controle de tráfego. Para seu funcionamento, devemos assumir que os pacotes
possam ser identificados e rotulados de acordo. A partir dessa e de outras técnicas, bem como de seus resultados, pesquisadores
tiveram o incentivo de pensar em um equipamento de alto desempenho que agisse sobre fluxos de informações na rede, onde estes
pudessem ser rotulados e encaminhados. Essa nova abordagem também deveria ser de menor impacto com relação ao prazo de
implementação e oferecer bom desempenho. Uma iniciativa bem-recebida foi a definição da interface e do protocolo OpenFlow –
oferecendo aos equipamentos de encaminhamento uma interface de programação simples, a qual possibilita analisar e controlar o que
fazer com cada pacote recebido. O encaminhamento (que é custoso) permanece eficiente, pois é realizado pelo hardware, enquanto a
parte menos exigente (quanto à agilidade) é feita pelo Software. Esse desacoplamento entre Hardware e Software, para permitir o
controle da rede via aplicações, é o paradigma que deu origem às Redes Definidas por Software ou Software Defined Networks (SDNs).
 Origens e Motivação
Historicamente, as SDNs possuem origem na arquitetura de redes Ethane, na qual tínhamos uma política e controle de acesso
distribuídos a partir da supervisão de um elemento central. No seu funcionamento, cada elemento da rede deve consultar esse
supervisor ao identificar um fluxo de informações novo. O elemento central toma a atitude (ou decide) o que fazer com o novo fluxo de
informações, a partir daquelas contidas em um grupo de políticas globais. Essa decisão é comunicada ao elemento de encaminhamento.
Tal modelo foi formalizado e deu origem à arquitetura OpenFlow, a qual será apresentada com mais detalhes em outra unidade. Do
ponto de vista prático, vemos hoje em dia que as mídias sociais, os dispositivos móveis e a computação em nuvem estão empurrando
as redes convencionais para os seus limites de capacidade. O aumento do poder de processamento e armazenamento tem alavancado
grandes inovações. Hoje, a gerência de rede pode tornar-se um limitante, pois é possível executar novas instâncias de processamento e
armazenamento de forma rápida, porém deixar uma rede ou parte dela parada por grande tempo devido a algumas operações mais
rígidas e que se exigem trabalho manual. Lins (2015) enumera da seguinte maneira os principais motivos para a utilização da SDN:
Clique nos botões para ver as informações.
Cada vez mais aplicativos acessam bancos de dados e servidores distribuídos por meio de serviços de nuvens que
requerem gestão do tráfego e acesso.
I. Mudançados padrões de tráfego 
Grande parte dos serviços é oferecido por acesso remoto.
II. Serviços em nuvens 
Cada vez mais aplicativos exigem processamento paralelo e uma demanda constante de conexão.
III. Largura de banda 
Dispositivos móveis e outros de diversos tipos tornaram a criação de políticas e o gerenciamento mais complexos,
demorados e manuais.
IV. Complexidade 
A tecnologia não deve �car “amarrada” a um fabricante; existe a necessidade de criação de padrões e interfaces.
V. Falta de escalabilidade/Dependência de fornecedor 
A própria Rede se encontra em um estado que a torna contrária a experimentar alterações ou mudanças de grande
impacto.
VI. Calci�cação da Rede 
Assim, uma Rede De�nida por Software (SDN) é uma arquitetura que pretende
ser:
Programável;
Controlada de modo central;
Ágil;
Econômica.
 De�nição de SDN
Quando iniciamos os estudos em SDN, geralmente nos deparamos com
outros tópicos e uma série de termos – como, por exemplo, OpenFlow,
entre outros que veremos nesta seção.
O meio de pesquisa apresenta diferentes definições para Redes Definidas por Software. A definição que adotaremos aqui é
normalmente referenciada como Open SDN, pois tipicamente utiliza o protocolo OpenFlow, daí o “Open” no seu nome. Segundo essa
definição, SDN é uma abordagem que visa desacoplar as funções do Hardware, que as implementa, e executá-las em Software. Em
outros termos, em SDN temos a separação do plano de controle e do plano de dados, utilizando-se o protocolo OpenFlow para a
comunicação entre as partes, conforme ilustrado na Figura 1.1.
 Figura 1.1 – Rede convencional vs SDN. Fonte: Baseada em decom.ufop.
Exemplo
Para explicarmos o que é uma SDN e seu funcionamento, utilizaremos um exemplo baseado em: youtube.com
 Continue lendo sobre Rede convencional e SDN
 Clique no botão acima.
javascript:void(0);
javascript:void(0);
Continue lendo sobre Rede convencional e SDN
Digamos que em um ambiente de rede tradicional podemos ter, por exemplo, quatro switches ou quatro
roteadores ou mesmo dispositivos de rede, conforme a Figura 1.1. Cada dispositivo possui, localmente, os
chamados: plano de controle e plano de dados (esses dois pontos serão mais bem-abordados em outra unidade).
Por ora, podemos ver o plano de controle como o “cérebro” do dispositivo. Localmente, o dispositivo possui uma
tabela de roteamento que, de modo breve, informa qual rota determinada mensagem, endereçada a algum
destino na Rede, deve seguir. Existem diversos protocolos de roteamento que, ao serem executados, criam essa
tabela de roteamento. Entre eles, podemos citar o protocolo OSPF (do inglês, Open Shortest Path First), que
atualiza as tabelas de roteamento nos dispositivos. Trata-se de um protocolo de roteamento distribuído, ou seja,
que roda em cada dispositivo e troca informações de roteamento entre eles. Logo, cada dispositivo possui
localmente o seu plano de controle, ou seja, cada dispositivo possui localmente um “cérebro” que trabalha
independentemente dos demais dispositivos, e mantêm um sincronismo de troca de informações entre eles.
Além disso, cada dispositivo possui um plano de dados local. O plano de dados cuida de como o tráfego de dados
é encaminhado de um dispositivo para outro. Se um dado chega ao equipamento por determinada porta
(digamos porta 1), o plano de dados atua para que esse dado que chegou pela porta 1 seja encaminhado para a
porta 2 do dispositivo, por exemplo.
Ou seja, a responsabilidade do plano de controle está relacionada ao aprendizado no encaminhamento de
pacotes (qual rota o pacote deve seguir), enquanto o plano de dados trata do encaminhamento de pacote, que
está associado a entradas na tabela de encaminhamento do equipamento.
Entre essas regras, podemos citar:
Encaminhar o pacote para uma porta especí�ca do dispositivo;
Alterar parte do cabeçalho dos pacotes;
Descartar;
Encaminhar para inspeção de um controlador.
Assim, se temos 100 switches na rede, temos 100 planos de controle e 100 planos de dados.
Além disso, cada dispositivo pode ser de uma marca diferente de vendedor (p. ex., Cisco, Juniper, Extreme etc.), e
cada um tem seu próprio sistema operacional. Dessa forma, não é simples criar um novo protocolo que possa ser
utilizado em todos os dispositivos sem grandes ajustes. Por exemplo, digamos que pretendemos criar um novo
protocolo de roteamento X, mas não existe uma interface aberta que me permita trocar o plano de controle e seu
plano de dados nesses switches, pois cada dispositivo possui seu Sistema Operacional proprietário, não sendo
possível trocá-los ou alterá-los, pois são proprietários.
Fazendo uma analogia, conforme Figura 1.2, podemos pensar em um App que desenvolvemos, executado tanto
em Windows quanto em Linux. Esses Sistemas Operacionais não dependem nem se abstraem da marca do
equipamento em que rodam, podendo ser HP, Dell etc. Temos a possibilidade de instalar e executar o App
independentemente da marca do dispositivo, não havendo necessidade de o App conhecer detalhes o
equipamento em que está rodando, por exemplo, o endereço de rede físico do dispositivo. Isso porque existe uma
Interface de Programação de Aplicativos (API; do inglês, Application Programming Interface) que faz a interação
entre o App e o Sistema Operacional (SO). Este último, por sua vez, esconde as complexidades dos dispositivos
para o App ou outras características físicas do hardware. Isso é chamado de abstração do hardware da aplicação,
a qual, entretanto, não existe para redes.
Em servidores, podemos criar aplicações que se valem da abstração com o SO (Windows, por exemplo), pois ele
esconde a complexidade do hardware em que a aplicação do desenvolvedor está instalada. O desenvolvedor não
precisa saber nem se preocupar com detalhes do hardware onde o App está. Ele pode desenvolver sua aplicação
em uma linguagem de programação em alto nível, como Python ou Visual Basic, sem se preocupar em qual
hardware sua aplicação (App) será executada.
Isso, no entanto, não é possível em um ambiente de rede; não se pode criar uma aplicação que será instalada nos
dispositivos de rede, pois estes são proprietários, e não se tem acesso ao código de Sistema Operacional dos
dispositivos para realizar alterações. Assim, a ideia do Open SDN e OpenFlow é criar uma interface aberta nos
dispositivos de rede, com uma camada de abstração que permita envolver ou cobrir o desenvolvimento de Apps.
Essa ideia introduz um controlador, como uma camada de abstração. O controlador acessa os dispositivos de
rede, utilizando um protocolo (nesse caso, o OpenFlow). OpenFlow provê uma API aberta para os dispositivos de
rede, a qual é indiferente ao sistema que está sendo executado nos dispositivos de rede.
De forma resumida, com essa organização de elementos, a aplicação (App) pode operar ou realizar modi�cações
no �uxo de informações que trafegam nos dispositivos de rede. A aplicação não precisa comunicar-se
diretamente com o hardware ou os dispositivos de rede; também não precisa saber detalhes físicos dos
dispositivos para entrar em funcionamento.
Se retornarmos à Figura 1.2, veremos 3 switches e um controlador. O “cérebro” de cada dispositivo que antes
estava no próprio dispositivo agora está no controlador; logo, em vez de cada um ter seu “cérebro” local, temos
um “cérebro” central que detém o controle e as políticas, tornando mais fácil o gerenciamento dos dispositivos.
Ou seja, as SDNs representam uma nova abordagem – mais dinâmica, gerenciável e com boa relação custo-
benefício –, podendo ser uma boa opção para a natureza e as exigências dos atuais aplicativos.
 Figura 1.2 – Analogia no desenvolvimento de Apps: Servidor vs Rede.
 Arquitetura SDN e seus Componentes
Aprendemos anteriormente que, em uma SDN, as decisões de encaminhamento passam a ser realizadas por um
elemento chamado controlador; já nas redes tradicionais, são executadas pelos dispositivos de rede (switches). Falamos
também sobre o protocolo utilizado nas comunicaçõesentre controlador e dispositivos de redes – o OpenFlow.
Agora, abordaremos os componentes de uma arquitetura SDN, que podem ser observados na Figura 1.3.
Na parte central temos o controlador (que pode ser de diferentes marcas: NOX, POX, FloodLight e BEACON). Esse
controlador se comunica com a infraestrutura (abaixo), ou seja, os dispositivos de rede roteadores, switches etc. O
protocolo que realiza essa comunicação é o OpenFlow.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Figura 1.3 – Arquitetura SDN. Fonte: Fraser et al. (2013).
Além disso, pela Figura 1.3, temos a Northbound API e SouthBound API, ambas implementadas em código aberto.
Basicamente o nome delas re�ete seu sentido de atuação, desde que coloquemos nosso referencial no controlador como
o centro da arquitetura – ou seja: Northbound API relacionado entre controlador e aplicações; e southbound API do
controlador para os dispositivos de rede.
Nas demais unidades, teremos mais informações sobre a atuação delas.
OpenFlow
O OpenFlow foi proposto pela
Universidade de Stanford com o
objetivo inicial de atender à
validação de novas propostas
de arquitetura e protocolos de
rede. O que costuma causar um
pouco de dúvida é que temos o
protocolo OpenFlow (que
estabelece como ocorre a
comunicação entre controlador
e dispositivos) e o Software
OpenFlow, que realiza essa
comunicação. Não somos
obrigados a utilizar o Software
OpenFlow em uma Rede SDN;
podemos fazer uso de outro
programa que também siga as
normas especi�cadas pelo
OpenFlow (padrão).
Controladores SDN
O componente central de uma
Rede De�nida por Software é o
controlador SDN, que, devido ao
seu funcionamento, também
pode ser considerado uma
espécie de “Sistema
Operacional” de rede. É o
componente que oferece uma
visão uni�cada da rede, sendo
responsável por concentrar a
comunicação com os
elementos programáveis dela.
Existem diversos controladores,
os quais serão apresentados
mais detalhadamente em outra
aula.
A forma de desenvolver
aplicações SDN depende do
controlador, bem como sua
arquitetura e complexidade.
Como pode ser visto na Figura
1.3, existem vários
controladores disponíveis,
como POX, NOX, Beacon,
Floodlight, cada um com suas
particularidades.
 Exemplos de Aplicações
 Clique no botão acima.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Exemplos de Aplicações
Devido à sua forma de funcionamento em uma rede SDN, as aplicações se tornam mais ativas, podendo
monitorar o estado da rede e se adaptar a ela. A seguir, veremos alguns exemplos de aplicações apresentados por
Pinhão et al. (2018).
Gerenciamento de redes
Um dos principais aspectos da SDN é a centralização da con�guração da rede, com a vantagem de oferecer uma
visão global do ambiente e possibilitar um monitoramento mais claro dos �uxos de interesse. Esse
monitoramento global permite, por exemplo, a aplicação de técnicas de inteligência arti�cial para a detecção de
anomalias na rede, como um ataque de negação de serviço.
A automatização oferecida pelas Redes De�nidas por Software promove a criação de abstrações em diferentes
camadas lógicas, o que aumenta a �exibilidade da rede.
Nas recentes aplicações de IoT (Internet of Things), temos um número crescente de dispositivos, além de uma
maior quantidade de tráfego na rede. Logo, o uso de uma SDN pode ajudar na análise dos �uxos e priorizar ou
alterar rotas, possibilitando maior e�ciência.
Qualidade de serviço | QoS
As SDNs e sua con�guração dinâmica têm impulsionado a pesquisa de muitos mecanismos. Um bom exemplo
são as aplicações com o objetivo de garantir uma melhor qualidade de serviço das Redes. Seria possível de�nir
regras de qualidade de serviço para toda rede, mesmo esta sendo composta de diferentes dispositivos.
Apesar disso, ainda faltam testes de QoS em nível de mercado com SDNs. É o que apontam pesquisas feitas em
empresas de primeira linha em Redes de Computadores. Podemos notar que a taxa de adoção de SDNs em
servidores de Internet (ISPs; do inglês, internet services providers) é muito impactada pela falta de pesquisa de
qualidade de serviço. Testes comparativos entre redes convencionais e SDNs demonstram desempenho similar,
com pequenas perdas de QoS da arquitetura SDN, devido ao atraso na veri�cação do �uxo de mensagens.
A Figura 1.4 apresenta o teste de um controlador de redes SDN em QoS. Na imagem, podemos ver um vídeo
distorcido (o de cima), devido à falta de prioridade do tráfego de vídeos sobre o tráfego de dados. Após adicionar o
módulo de QoS no controlador, temos como resultado a imagem de baixo, sem distorções.
 Figura 1.4 – Comparação de um vídeo com e sem QoS.
Controle de acesso
O controle de acesso é outro de exemplo de aplicação que pode ser realizado pelo controlador. Isso permite
veri�car: o protocolo em uso, a origem e o destino do pacote; o usuário etc. Desse modo, pode-se escolher uma
rota diferente para algum �uxo especí�co – o que possibilita termos vários �ltros atuando no controlador, com
objetivos variados, entre eles: inspeção de pacotes, isolamento de pontos etc.
Economia de energia
Em sistemas de Computação, uma questão importante é a economia de energia – empresas de
Telecomunicações estão entre as que mais consomem energia.
A SDN pode auxiliar na redução de energia, pois, ao se ter uma visão global da rede, é possível identi�car as rotas
mais utilizadas e também as subutilizadas, bem como reduzir a taxa de transmissão em alguns enlaces, ou
mesmo desligar pontos e dispositivos da rede.
5. Conclusão
Nesta unidade, apresentamos os conceitos da arquitetura de redes SDN, sua origem e funcionamento, assim como suas
aplicações em Redes de Computadores e os desa�os dessa tecnologia.
As SDNs impactam consideravelmente as redes convencionais, pois desacoplam o plano de controle do plano de dados, o
que traz diversas vantagens no desenvolvimento de aplicações e qualidade de serviço, tornando esta uma tecnologia
extremamente atrativa.
Entretanto, tal tecnologia ainda se encontra em amadurecimento, carecendo de grandes casos de uso para garantir sua
qualidade no mercado e iniciar uma migração de tecnologia por parte dos grandes operadores de rede para SDN.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Atividade
1. O que impulsionou o desenvolvimento de uma nova arquitetura de rede?
a) As aplicações exigirem acesso remoto à tecnologia e nuvens.
b) A necessidade de estabilidade da Internet.
c) A necessidade crescente de armazenamento.
d) A exigência de maior poder de processamento.
e) A necessidade crescente de redução do consumo de energia.
2. Por que podemos a�rmar que a infraestrutura da rede atual (Internet) é considerada “ossi�cada”?
a) Pois a infraestrutura atual está rígida a modificações.
b) Pois toda a comunicação digital se apoia em seu uso.
c) Pois toda a sua construção foi feita em partes ou módulos, como encaixe.
d) Pois é antiga e desgastada.
e) Pois pode ser rompida (quebrada) mediante um ataque.
3. Podemos citar como componentes de uma SDN:
a) Controlador, plano de dados e plano de controle.
b) Elementos de rede (switch), OpenFlow e controlador.
c) Elementos de comutação programáveis, controlador e aplicações de rede.
d) OpenFlow, northbound e controlador.
e) Southbound API, controlador e OpenFlow.
4. Qual a grande diferença entre a arquitetura SDN e a arquitetura de rede tradicional?
a) O desacoplamento dos planos de trabalho e controle.
b) O desacoplamento do plano de controle e plano de dados.
c) O desacoplamento dos planos de dados e gerenciamento.
d) Um elemento central comandante da rede.
e) A utilização do protocolo OpenFlow.
5. Quais as principais funções do plano de controle e dados?
a) O plano de dados realiza o encaminhamento de pacotes, enquanto o plano de controle define as rotas de pacotes na rede.
b) O plano de controle, como o próprio nome diz, realiza o controle dos dispositivos, e o plano de dados padroniza o formato de
dados suportadopelos equipamentos.
c) O plano de controle realiza o encaminhamento de pacotes, enquanto o plano de dados define as rotas de pacotes na rede.
d) O plano de dados e o plano de controle fazem basicamente as mesmas funções; seus nomes são diferentes de acordo com quem
executa determinada ação.
e) O plano de dados formata os dados recebidos a partir de ordens ou comandos do plano de controle de uma rede.
6. Como, por exemplo, um controlador SDN pode realizar QoS?
a) A partir de sua agilidade ao tratar dados no plano de dados.
b) Ao melhorar o controle feito no dispositivo para apresentar as informações ao cliente.
c) Por meio de uma melhor seleção de qual serviço realizar primeiro.
d) Por meio da definição de prioridades diferentes para os fluxos de pacotes que chegam no dispositivo.
e) Negando ou delegando uma série de ações a outro dispositivo e, dessa forma, distribuindo melhor as tarefas entre todos os
dispositivos envolvidos.Referências
FLAUZAC, O.; GONZALEZ, C.; HACHANI, A.; NOLOT, F. SDN based architecture for iot and improvement of the security. 29th
I t ti l C f Ad d I f ti N t ki d A li ti W k h 2015
Notas
International Conference on Advanced Information Networking and Applications Workshops, 2015.
FRASER, B. et al. Are we ready for SDN? Implementation challenges for Software-De�ned Networks. IEEE Communications
Magazine, 2013.
HU, F. et al. Network Innovation through OpenFlow and SDN: Principles and Design. CRC Press, 2014.
GUEDES, D. et al. Redes De�nidas por Software: uma abordagem sistêmica para o desenvolvimento das pesquisas em Redes
de Computadores. Minicurso 4 do XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos. Maio, 2012.
[Online]. Disponível em: //homepages.dcc.ufmg.br/~mmvieira/cc/papers/minicurso-sdn.pdf. Acesso em: março, 2019.
KUROSE, J.; ROSS, K. Computer Networking: a top down approach. 2017, 7th ed.
LINS, T. Redes De�nidas por Softwre (Software De�ned Networks) SDN. [Online]. Disponível em:
//www.decom.ufop.br/imobilis/redes-de�nidas-por-software-software-de�ned-networks-sdn/. Laboratório Imobilis Computação
Móvel. Acesso em: março, 2019.
LOBATO, A.; FIGUEIREDO, U.; ALVES. L. Trabalho da disciplina de Redes de Computadores I – UFRJ (2013.1). [Online].
Disponível em: https://www.gta.ufrj.br/grad/13_1/sdn/index.html. Acesso em: março, 2019.
Sdx Central. Disponível em: https://www.sdxcentral.com/networking/sdn. Acesso em: março, 2019.
PINHÃO, G.L.L.; GAMA, L.V.; COSTA, R.E.S. Trabalho da disciplina de Redes de Computadores I – UFRJ (2018.1). [Online].
Disponível em: https://www.gta.ufrj.br/ensino/eel878/redes1-2018-1/trabalhos-vf/sdn/. Acesso em: março, 2019.
Próxima aula
Aplicações que envolvam SDN;
Aplicações que envolvam SDN;
Explore mais
youtube.com <https://www.youtube.com/watch?v=l-DcbQhFAQs&t=9s>
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
https://www.youtube.com/watch?v=l-DcbQhFAQs&t=9s