Redes Definidas por Software
Redes Definidas por Software
Autores: Lucas Chagas, Raphael Evangelista Filene
Universidade Federal do Rio de Janeiro (UFRJ)
Departamento de Engenharia Eletrônica (DEL)
Engenharia de Computação e Informação (ECI)
EEL879 - Redes de Computadores 2 - 2018.2
Professor: Luís Henrique M. K.
O sucesso da área de redes e da Internet é algo que pode ser observado com facilidade. Muitas das atividades realizadas atualmente estão conectadas de algum modo às redes de computadores, de tal modo que sem a Internet diversos serviços essenciais para o funcionamento da sociedade parariam de funcionar. Entretanto, essa dependência trouxe consigo uma expectativa de que a Internet estará sempre estável e funcional. Logo, implantar novas tecnologias e protocolos se torna uma tarefa árdua, dado que há um risco de interrupção de atividades que não é aceitável na conjuntura atual. Com essa inflexibilidade da arquitetura de redes, passou-se então a afirmar que a Internet está "calcificada".
É com este contexto que começou a ser desenvolvida a tecnologia de Redes Definidas por Software (SDN). Esta foi feita de modo a permitir um gerenciamento automático e eficiente da rede, facilitando o controle de múltiplas redes de computadores e a implementação de novas tecnologias e protocolos.
Redes Definidas por Software (SDN) são caracterizadas pela separação física entre o plano de controle e o plano de dados. Com essa separação, o controle de mecanismos de encaminhamento passa a ser implementado através de uma interface de programação implementada mediante um controlador, que fica localizado no plano de controle. Desse modo, através dessa interface o administrador de rede é capaz de inspecionar, definir e alterar as entradas da tabela de roteamento dos comutadores desejados, e estes passam a ser responsáveis somente pelo processo de encaminhamento dos pacotes recebidos. Além disso, com SDN um controlador passa a ser responsável pelo gerenciamento de múltiplos nós da rede, abrindo assim a possibilidade de toda a rede ser configurada a partir de um único nó central. Ao abstrair a infraestrutura da rede de modo a facilitar a construção de novas aplicações e serviços, a tecnologia busca reduzir a atual "calcificação" vista na Internet.
Sendo o principal elemento do plano de controle, o controlador oferece uma visão única e centralizada da rede. Este fornece à SDN a capacidade de gerenciar o fluxo de pacotes nos switches e roteadores, e é responsável por implementar as regras que classificarão os fluxos recebidos.
A visão global da topologia da rede possibilita o desenvolvimento de análises detalhadas sobre características do funcionamento da rede, permitindo assim que sejam tomadas decisões eficientes sobre quais modificações devem ser implementadas para garantir o bom funcionamento do sistema. A existência dessa visão global, além de simplificar o processo de tomada de decisões, também facilita a implementação dessas decisões para todos os elementos da rede.
Outra característica do controlador se dá pelo seu impacto na classificação dos pacotes recebidos, tendo um papel central no processo de criação da tabela de fluxos a ser seguida pela rede. É através dele que se fornece um ambiente de programação onde podem ser desenvolvidas aplicações que decidem o próximo salto de um fluxo. Essa interface de programação provê um meio de mais alto nível para definir as funções dos elementos de rede, o que facilita o desenvolvimento de funções voltadas para esta área. Além disso, essa programabilidade permite que seja implementada uma maior gama de funções lógicas voltadas para o monitoramento do fluxo na rede.
Estas APIs são conjuntos de rotinas, protocolos e ferramentas responsáveis por possibilitar a comunicação entre os planos de controle e dados, assim como entre o controlador e aplicações que atuam diretamente na definição de políticas de rede. Essas APIs inicialmente dividem-se em Northbound, responsável pela comunicação entre essas aplicações utilizadas pelo administrador de rede e o plano de controle, e Southbound, responsável pela comunicação entre os planos de controle e dados.
A figura abaixo apresenta uma versão simplificada da arquitetura SDN, explicitando a separação entre os planos de aplicação, controle e dados, assim como os elementos que compõem cada plano e as APIs que os conectam.
Neste plano ficam presentes as aplicações responsáveis por criar e implementar novas funções que atuarão no contexto de SDN, sendo desse modo responsáveis pelo gerenciamento da rede. Estas funções podem, por exemplo, definir as políticas de rede estabelecidas no controlador. É através desse plano que o administrador de rede pode interagir diretamente com os elementos que compõem a rede, e alterar o modo como estes atuam conforme o desejado.
A Northbound API é responsável pela comunicação entre o plano de aplicações e o plano de controle, permitindo que aplicações responsáveis pelo controle de funções de rede possam atuar sobre a ela de modo correto. Desse modo, esta interface é responsável por transmitir os requisitos dessas aplicações para camadas inferiores, assim como retornar as possíveis respostas e estatísticas da rede para as aplicações que originaram esses requisitos.
Como dito anteriormente, o plano de controle passa a ser responsável pela parte "inteligente" da rede em uma SDN através da implementação de um controlador. De modo a facilitar a adoção de novas políticas de rede e a modificação das já existentes, é também nesse plano que é implementada a interface responsável por permitir ao administrador realizar as mudanças desejadas. Para reduzir erros e propiciar uma adesão maior à tecnologia, esta interface foi implementada de modo que todas as alterações possam ser feitas de modo simples e intuitivo.
A principal função oferecida pelo controlador é a capacidade de priorizar ou bloquear pacotes que sejam recebidos pela rede, sendo responsável por processar e definir quais serão as rotas seguidas por tais pacotes. Outras funções incluem a análise do estado da rede, a obtenção de informações sobre sua topologia e o gerenciamento dos dispositivos que a compõem. É também através dele que são definidas e impostas as regras responsáveis pela comunicação entre serviços e aplicações.
A Southbound API é um dos principais elementos responsáveis por possibilitar a separação do plano de dados do plano de controle. É através dela que o controlador é capaz de enviar ao plano de dados informações necessárias para este realizar a classificação dos pacotes, assim como reprogramar os equipamentos de modo a implementar funções como controle de fluxo e firewall. É também através desta interface que fluxos novos e, consequentemente, desconhecidos, são enviados pelos equipamentos ao controlador para que este possa classificá-los.
Após a divisão, este plano ficou responsável somente pelo encaminhamento dos pacotes na rede, sendo composto por elementos responsáveis por realizar este processo como roteadores, comutadores e switches. Entretanto, diferentemente de suas versões tradicionais, eles não utilizam protocolos de roteamento ou outros algoritmos complexos dentro de si, dado que estes são agora implementados pelo plano de controle.
O modo como o plano de dados atua depende principalmente de como o plano de controle realiza a comunicação com ele, ou seja, diferentes Southbound APIs fazem com que este plano execute suas funções de modos variados. Utilizando de exemplo o OpenFlow como Southbound API, os dispositivos no plano de dados dependerão somente de uma tabela de fluxos para examinar, tratar e direcionar os fluxos recebidos. Um fluxo, de acordo com a RFC 3917, é um conjunto de pacotes IP passando por um ponto de observação na rede durante um determinado intervalo de tempo.
Essas tabelas de fluxo atuam examinando o cabeçalho dos pacotes recebidos bit a bit, lendo informações como IP de origem e destino, portas de origem e destino, protocolo, dentre outros, e comparando-os com os valores presentes na tabela. Quando os valores encontrados forem compatíveis, ações podem ser tomadas para aquele fluxo, com estas geralmente sendo encaminhá-lo por um caminho específico ou descartá-lo. Outras ações incluem mandá-lo para a próxima tabela de fluxos ou, caso seja um fluxo novo, enviá-lo ao controlador para descobrir que ação deve ser tomada para casos similares.
As tabelas de fluxo também mantêm estatísticas de utilização, com informações a respeito da frequência em que cada entrada na tabela é examinada, que podem ser retornadas ao administrador para que este tenha maior informação e controle sobre detalhes da rede.
Uma importante característica da área de SDN é a presença de variadas ferramentas, muitas de código aberto, criadas de modo a implementar os elementos necessários para o funcionamento da tecnologia. O OpenFlow, sendo o primeiro protocolo de comunicação implementado tendo em mente a utilização em SDN, atualmente é a principal Southbound API utilizada. Muitas outras ferramentas fazem uso desta API ou implementam melhorias baseando-se nela, como por exemplo o Open vSwitch (comutador virtual utilizando OpenFlow) e o OVSDB, que implementa o protocolo OpenFlow de modo a este ser compatível com o Open vSwitch. Outras ferramentas importantes são implementações de controladores, como por exemplo o OpenDaylight, que são essenciais para o funcionamento do plano de controle e consequentemente da rede.
Concebido inicialmente nas universidades de Stanford e da Califórnia em Berkeley em 2007, este protocolo é responsável por permitir a manipulação e o acesso direto a equipamentos no plano de dados. Sua funcionalidade advém do uso de uma tabela de fluxos, com os fluxos recebidos sendo comparados aos valores na tabela e o equipamento de rede executando as ações correspondentes, conforme indicado.
Servindo como a principal Southbound API utilizada por implementações de SDN, este protocolo foi adotado como o padrão pela Open Networking Foundation. Esta é uma organização dedicada à promoção e adoção de SDN, tendo como parceria múltiplas grandes empresas voltadas à área tecnológica, como Google, Microsoft, Cisco, dentre outras, e que atua principalmente incentivando o desenvolvimento de padrões abertos voltados à SDN.
A principal característica da classificação utilizada pelo OpenFlow é a abstração dos pacotes recebidos em fluxos. Um fluxo é caracterizado por um conjunto de pacotes, dentro de uma determinada janela de tempo, que possui valores iguais em alguns campos do cabeçalho. O protocolo disponibiliza um total de 12 campos que podem ser utilizados para a classificação dos fluxos recebidos, incluindo IPs de origem e destino, portas de origem e destino, o protocolo da camada de transporte, dentre outros.
Assim, torna-se possível a criação de modelos de encaminhamento baseando-se em uma combinação de valores de cabeçalho definida pelo administrador de rede, o que abre uma gama de oportunidades para aqueles interessados em ter um controle maior sobre características da rede. De modo geral, o OpenFlow possibilita a implementação de funcionalidades de hardwares, utilizados na rede tradicional, através da definição de um conjunto simples de regras e de uma tabela de fluxos. As regras criadas incluem as ações que devem ser executadas pelos dispositivos no plano de dados, ações essas que, atuando diretamente nos fluxos examinados, incluem encaminhar, descartar, enviar para o controlador, dentre outras. A imagem abaixo demonstra, de modo simplificado, como atua o protocolo.
O Open vSwitch é um comutador virtual distribuído, de código aberto, que implementa o protocolo OpenFlow. Sua função é simular comutadores em ambiente virtuais, permitindo que máquinas virtuais comuniquem-se entre si de modo equivalente a uma rede comum. Dentre as vantagens que ele traz, destaca-se a capacidade de simular variadas topologias de rede em um ambiente limitado, permitindo que testes de novas funções virtuais de rede possam ser feitos com maior facilidade.
O Open vSwitch foi projetado de modo a permitir configuração e programação de forma automatizada, sendo capaz de se integrar com múltiplos protocolos e padrões utilizados na área de redes. Dentre os recursos oferecidos pelo Open vSwitch, destacam-se: criação e modificação de VLANs e firewalls, modelagem e enfileiramento do tráfego, assim como ferramentas para monitoramento da rede, como o Netflow e o sFlow. Seu código foi escrito em C, tendo em mente facilitar sua portabilidade para variados ambientes.
Liderado pela comunidade e suportado pela indústria, o controlador OpenDaylight é uma ferramenta de código aberto que visa suprir as necessidades que possam surgir com o avanço das tecnologias de SDN e NFV. Sendo uma plataforma multiprotocolo e modular, esta possui suporte para múltiplos protocolos envolvendo SDN, incluindo OpenFlow e OVSDB, e foi desenvolvido de modo a facilitar a adoção novos protocolos conforme estes forem desenvolvidos e implementados.
Este controlador é implementado completamente por software, tendo sido desenvolvido de modo a funcionar através de uma máquina virtual Java. Desse modo, ele pode ser implementado em qualquer plataforma que ofereça suporte à esta linguagem. Outra característica é a adoção de APIs Northbound abertas, o que facilita o desenvolvimento de aplicações que possam se comunicar com facilidade ao controlador.
O FlowVisor funciona como um controlador especial, atuando como um middleware entre comutadores e outros controladores fazendo uso do protocolo OpenFlow. Todas as requisições feitas entre um comutador e um controlador passam pelo FlowVisor, com as mensagens trocadas entre dispositivos nos planos de dados e controle sendo desse modo transmitidas pela ferramenta.
Sua importância reside no fato de possibilitar a divisão da rede entre múltiplos controladores, garantindo o isolamento entre as divisões criadas. Essa divisão pode ser feita utilizando elementos como os endereços ethernet e IP ou pelos protocolos das mensagens trocadas, por exemplo. Com esse isolamento, um controlador não é capaz de ver o fluxo de um comutador que não está sob seu controle, pois garante-se que cada controlador tem visão e acesso somente aos dispositivos da parte da rede atribuídos à ele.
Embora consista num grande desafio para a indústria de redes, uma das grandes aplicações do SDN são as redes domésticas.
Uma forma de aplicar os princípios de SDN nesse contexto é utilizar um roteador doméstico com recursos OpenFlow e transferir para o provedor de acesso a responsabilidade de controlar a rede atraves de um controlador SDN. Dessa forma, esse sistema operacinal de rede seria capaz de programar cada roteador domestico com as regras de acesso apropriadas para cada usuario e ter uma visão global de todo o tráfego que atravessa o enlace de acesso a cada residencia, construindo dessa forma uma visão agregadado que pode ser considerado tráfego lícito e quais padrões de tráfego podem indicar a ação de atacantes ou código malicioso.
Por outro lado, outra solução interessante pode ser a implementação de um controlador de rede interno à rede doméstica. Essa solução se torna atraente especialmente frente ao aumento da complexidade dessas redes, que contam hoje com um número crescente de dispositivos ativos, como smartphones e consoles de jogos, além dos computadores usuais. Além disso, essa solução poderiam contar com mais de um elemento de comutação, tanto para enlaces cabeados quanto para enlaces sem fio. Assim, um controlador doméstico poderia acompanhar todo o tráfego interno de rede, tornando mais simples a detecção de malwares e a configuração de serviços da rede, como impressoras e novos dispositivos de acesso.
Espera-se que o tráfego de dados móveis cresça mais rápido que a Internet fixa nos próximos anos e as futuras redes móveis devem ser dimensionadas para acomodar esse crescimento esperado do tráfego. Para acompanhar esse avanço, as redes móveis precisam passar por processos de atualização de suas arquiteturas não apenas de modo a otimizar os recursos atuais, mas também para adicionar novos componentes e tecnologias. No entanto, redes de backhaul móveis contêm dispositivos extremamente complexos e inflexíveis.
Nessas bases, o SDN é uma das tecnologias promissoras que deverá resolver essas limitações nas redes móveis atuais. A SDN fornece as melhorias necessárias em flexibilidade para adaptar a rede móvel de modo que esta acompanhe o crescimento esperado. A proposta de redes móveis definidas por software (SDMN) direciona a arquitetura atual da rede móvel para um modelo centrado em fluxo, que emprega hardware barato e um controlador logicamente centralizado. Neste caso, o plano de controle dos elementos da rede móvel pode ser implantado em uma nuvem da operadora de telecomunicações responsável por oferecer a cobertura de acesso à rede.
Nesse paradigma, cada operador tem a flexibilidade de desenvolver seus próprios conceitos de rede, otimizar sua rede e atender às necessidades específicas de seus assinantes. Além disso, os switches de rede programáveis por software no SDMN usam metodologias modernas de programação ágil. Essas metodologias de software podem ser desenvolvidas, aprimoradas e atualizadas em ciclos muito mais curtos do que o desenvolvimento dos dispositivos modernos de rede de backhaul móvel de última geração.
A aquisição da virtualização em redes móveis LTE traz a vantagem econômica de duas maneiras. Primeiramente, SDMN requer hardware barato, como servidores de baixo custo e switches em vez de dispositivos de backhaul móveis caros. Segundo, a introdução da tecnologia SDN permite a entrada de novos atores no ecossistema de redes móveis, como fornecedores independentes de software (ISVs) e provedores de nuvem, introduções essas que potencialmente causarão um grande impacto no modelo de negócios de redes móveis que temos atualmente.
SD-WAN (ou SDWAN) é uma aplicação que trata de conceitos tanto de SDN quanto de redes WAN. Estas redes são utilizadas para conectar elementos separados por largas áreas geográficas, frequentemente presentes em países ou continentes diferentes. A própria Internet pode ser considerada uma WAN.
Uma WAN pode ser usada, por exemplo, para conectar filiais a uma rede corporativa central ou para conectar data centers separados por grandes distâncias. Atualmente, essas conexões frequentemente utilizam tecnologia que exige hardware proprietário especial. A proposta de SD-WAN procura mover mais do controle de rede para a nuvem, usando uma abordagem de software.
O principal objetivo de SD-WAN é fornecer uma conexão WAN habilitada para nuvem de classe empresarial, segura e simples, implementada utilizando ao máximo tecnologia aberta e baseada em software. Esta tecnologia pode ser usada para fornecer conectividade básica de WAN, ou para oferecer serviços comerciais premium, como VPN, otimização de WAN e controle de entrega de aplicativos.
Sendo uma tecnologia ainda em seus estágios iniciais de desenvolvimento, SDN ainda possui muitos desafios a superar antes que possa ser adotada como uma arquitetura padrão de redes. Dentre esses desafios, destacam-se os riscos de segurança, os problemas desempenho, a questão da escalabilidade, a interoperabilidade de equipamentos que fazem uso de SDN e a confiança necessária ao se utilizar uma arquitetura centralizada.
Ao propor uma tecnologia em que um dos principais aspectos é a centralização através de um controlador, SDN se depara com um problema o qual as redes atuais não precisam lidar: a escalabilidade. Todos os principais problemas relacionados à escalabilidade que surgem com a tecnologia se devem a introdução de um ponto único de falha, problemas estes que se tornam ainda mais evidentes conforme a rede cresce. Em um cenário de Internet das Coisas (IoT), esse é, em conjunto com a segurança, um dos principais desafios a serem superados antes que a tecnologia de SDN possa ser introduzida em maior escala.
Um exemplo dos problemas introduzidos é a escalabilidade do controlador. Sendo este limitado por quão rapidamente ele consegue responder aos dispositivos que ele controla, falhas começam a surgir na rede caso o número de dispositivos requerendo informações seja maior que a velocidade de processamento disponibilizada. Ao depender de somente um controlador, o processamento disponível pode rapidamente não ser capaz de atender aos dispositivos caso estes estejam em grande quantidade.
Uma possível solução para a questão da escalabilidade é implementar o controlador de maneira distribuída. Porém, para aplicar esta proposta é necessário serem implementados protocolos capazes de realizar a comunicação entre os múltiplos elementos. Essa necessidade de comunicação e de sincronia gera custos extras a rede, que podem afetar o desempenho desta a ponto de afetar a qualidade de serviço desejada. Soluções estão sendo desenvolvidas para tratar deste desafio, através da introdução de APIs denominadas East/Westbound. Atualmente, cada controlador implementa sua própria versão dessas APIs, que são responsáveis por transportar dados entre os controladores, verificar se os dados são compatíveis entre si, se as políticas de rede são equivalentes, dentre outras funções. O quanto essas APIs afetam o desempenho da rede, e como reduzir esse impacto, é outro desafio que deve ser solucionado.
A tecnologia de SDN possui muitos desafios de segurança em comum com os apresentados por redes tradicionais, além de outros introduzidos por características próprias de sua arquitetura. Muitos dos problemas introduzidos, que também estão ligados à questão da escalabilidade, são devido ao controlador ser um ponto único de falha, possibilitando que ataques neste ponto afetem toda a rede.
Uma das principais vulnerabilidades enfrentadas por SDN são ataques de negação de serviço (DoS). O objetivo destes é inundar a rede com um grande número de pacotes em um curto espaço de tempo, sobrecarregando assim o controlador. Segundo o processo usualmente adotado por protocolos que implementam SDN, o próprio OpenFlow sendo um exemplo neste caso, quando um fluxo desconhecido for encontrado informações a seu respeito devem ser enviadas ao controlador para decidir o que deve ser feito para fluxos similares. Esse envio pode ser feito de dois modos: enviando-se o fluxo completo ao controlador ou armazenando o conteúdo do fluxo no dispositivo do plano de dados e enviando somente o cabeçalho ao controlador. Ambos apresentam um problema no caso de um ataque de DoS: enviar o fluxo completo congestiona o canal, comprometendo o desempenho da rede; por outro lado, como o conteúdo dos fluxos ficam armazenados em buffers de tamanho limitado, enviar somente o cabeçalho pode rapidamente levar à perda de pacotes caso se estoure a capacidade da fila.
Outra vulnerabilidade introduzida vem do fato de muitas vezes a implementação de SDN se dar através de padrões abertos e conhecidos. Desse modo, atacantes podem utilizar o conhecimento sobre características da rede para descobrir e se aproveitar de possíveis vulnerabilidades. Invadir uma rede ou implementar código malicioso se tornam então falhas de segurança com um risco considerável de ocorrerem, e são desafios descobrir métodos tanto para evitar que estes ataques ocorram quanto para tratar das consequências de modo a minimizar os danos causados.
A latência introduzida pela necessidade de comunicação entre os dispositivos nos planos de controle e dados é outro desafio introduzido por SDN. Como anteriormente estes planos estavam acoplados, a comunicação necessária ocorria sem afetar significativamente o desempenho da rede, o que deixa de ocorrer com a separação dos planos. Além disso, o tempo de processamento do controlador é outro fator que gera impacto no desempenho da rede como um todo: quanto mais esse demora para processar os fluxos recebidos, maior é o impacto causado. Desse modo, de modo a tratar destes dois desafios relacionados ao desempenho da rede, projetos precisam ser desenvolvidos visando mitigar o impacto causado pela adoção da nova tecnologia.
Um exemplo de projeto, feito com intuito de acelerar o tempo de processamento gasto no controlador, é o NOX-MT. Este é um controlador baseado no NOX, tendo como diferencial a adição de multithreading e conhecidas técnicas de otimização. Outro projeto desenvolvido com objetivos similares é o Floodlight, outro controlador desenvolvido tendo multithreading em mente. Este é um controlador baseado em Java, feito de modo a atuar segundo o protocolo OpenFlow.
Por fim, um importante aspecto de SDN é a necessidade de todos os dispositivos serem capazes de comunicarem-se entre si, comunicação esta realizada através de APIs. Entretanto, grande parte do que foi implementado até então não foi feito segundo algum padrão; pelo contrário, múltiplos protocolos e APIs estão sendo desenvolvidos, o que dificulta a definição de um modelo a ser seguido. A exceção neste caso é o protocolo OpenFlow, que frequentemente serve como base para outras Southbound APIs.
Com a falta de um padrão para APIs Northbound e East/Westbound, surge assim uma maior possibilidade de ocorrerem problemas devido à falhas de comunicação entre controladores e aplicações. Além disso, a necessidade de adaptar aplicações para funcionarem segundo múltiplas interfaces Northbound gera um gasto de capital maior para empresas potencialmente interessadas em investir na tecnologia, afetando assim seu crescimento e evolução.
Apresentamos neste trabalho os principais conceitos de SDN, assim como uma visão básica de sua arquitetura, suas principais ferramentas, aplicações, e os desafios que enfrenta atualmente. Esta é uma área que que vem sendo alvo de muitos estudos para variados ramos da tecnologia, sendo uma das mais promissoras no ramo de redes que possuímos atualmente.
Como visto, as principais vantagens de redes definidas por software vem da tentativa de escapar da "calcificação" observada atualmente pela arquitetura de rede, ao tornar possível a implementação de novas tecnologias e protocolos. Isto torna SDN um alvo de grandes empresas e organizações do setor de tecnologia de informação, com Google e Microsoft, que atuam como patrocinadores para o desenvolvimento de pesquisa na área. Apesar disso, esta ainda é uma tecnologia em seus estados iniciais de amadurecimento, e muitos são os desafios que precisam ser superados perante as características da rede atual antes que SDN possa se tornar uma arquitetura padrão de redes.
Um dos principais aspectos da tecnologia de SDN, quando comparada à arquitetura de rede tradicional, é a separação dos planos. Como os planos são separados, e quais as funções de cada um?
Os planos são separados em plano de controle e plano de dados. O plano de controle fica responsável pela parte "inteligente" da rede, sendo responsável por determinar quais as rotas seguidas por novos pacotes, enquanto o plano de dados é responsável pelo encaminhamento físico desses pacotes.
Explique como ocorre o encaminhamento de pacotes no protocolo OpenFlow:
Quando o fluxo dos pacotes sendo recebidos ainda não está definido, o OpenFlow envia os pacotes para o controlador de modo a este definir que ação deve ser tomada para fluxos semelhantes. Os fluxos são então enviados novamente ao plano de dados para que sejam então encaminhados de acordo com as definições feitas pelo controlador, e todo fluxo subsequente que se encaixe no mesmo elemento na tabela de fluxos seguirá pelo mesmo caminho.
Uma das principais motivações para o desenvolvimento de SDN dá-se ao afirmar que a estrutura de rede atual está “calcificada”. Explique o significado do termo:
Devido a necessidade de a Internet estar sempre estável, dificulta-se o processo de desenvolvimento de novas aplicações e protocolos de rede pelo risco de interrupção das atividades. Essa imutabilidade da rede fez com que esta passasse a ser considerada “calcificada”.
Por que a utilização de SD-WANs pode ser uma aplicação de grande interesse para uso empresarial?
Pois ela permite a criação de WANs de alto desempenho por baixos custos, dado que essa implementação é feita em hardware genérico e configurada por software. Essas WANs podem ser utilizadas para conectar filiais ou data centers separados por largas distâncias.
Cite os 4 principais desafios que a área de SDN enfrenta atualmente:
Os desafios são: escalabilidade, segurança, desempenho e interoperabilidade.
[1] KREUTZ, Diego; RAMOS, Fernando M. V.; VERÍSSIMO, Paulo Esteves; Rothenberg, Christian Esteve; AZODOLMOLKY, Siamak; UHLIG, Steve. "Software-Defined Networking: A Comprehensive Survey", Proceedings of the IEEE, Janeiro, 2015. Disponível em: https://ieeexplore.ieee.org/document/6994333/ Acessado em 26 de Agosto de 2018
[2] GUEDES, Dorgival; VIEIRA, Luiz Filipe Menezes; VIEIRA, Marcos Menezes; RODRIGUES, Henrique; NUNES, Rogério Vinhal. “Redes Definidas por Software: uma abordagem sistêmica para o desenvolvimento das pesquisas em Redes de Computadores”, Minicurso do XXX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, Maio, 2012. Disponível em: http://homepages.dcc.ufmg.br/~mmvieira/cc/papers/minicurso-sdn.pdf Acessado em 26 de Agosto de 2018
[3] KREUTZ, Diego; RAMOS, Fernando M. V.; VERÍSSIMO, Paulo Esteves. “Towards Secure and Dependable Software-Defined Networks”, ACM New York, Agosto, 2013. Disponível em : https://www.ietf.org/proceedings/87/slides/slides-87-sdnrg-2.pdf Acessado em 26 de Agosto de 2018
[4] BUTLER, Brandon. “What SDN is and where it’s going”, Network World, Julho, 2017. Disponível em: https://www.networkworld.com/article/3209131/lan-wan/what-sdn-is-and-where-its-going.html Acessado em 26 de Agosto de 2018
[5] OPEN NETWORKING FOUNDATION, "Software-Defined Networking (SDN) Definition". Disponível em: https://www.opennetworking.org/sdn-definition/ Acessado em 26 de Agosto de 2018
[6] SEZER, S.; SCOTT-HAYWARD, S.; CHOUHAN, P. K.; FRASER, B.; LAKE, D.; FINNEGAN, J.; VILJOEN, N.; MILLER, M.; RAO, N.. “Are We Ready for SDN? Implementation Challenges for Software-Defined Networks”, IEEE Communications Magazine, Julho, 2013. Disponível em: https://ieeexplore.ieee.org/document/6553676/ Acessado em 26 de Agosto de 2018
[7] LIGUORI, Angelo; WINANDY, Marcel. "The Diamond Approach for SDN Security", IEEE Softwarization, Março, 2018. Disponível em: https://sdn.ieee.org/newsletter/march-2018/the-diamond-approach-for-sdn-security Acessado em 26 de Agosto de 2018
[8] JAMMAL, Manar; SINGH, Taranpreet; SHAMI, Abdallah; ASAL, Rasool; LI, Yiming. "Software defined networking: State of the art and research challenges", Computer Networks, Julho, 2014. Disponível em: https://ac.els-cdn.com/S1389128614002588/1-s2.0-S1389128614002588-main.pdf?_tid=e1cc7a13-6eb8-4624-8532-332f1fd97d66&acdnat=1536675943_8409c98826bfbf8d0c9bd62a6cb6d753 Acessado em 11 de Setembro de 2018
[9] GUEDES, Dorgival; VIEIRAL, Luiz Filipe Menezes; VIERAL, Marcos Menezes. "Redes Definidas por Software: uma abordagem sistemica para o desenvolvimento das pesquisas em Redes de Computadores" Disponível em: https://homepages.dcc.ufmg.br/~mmvieira/cc/papers/minicurso-sdn.pdf Acessado em 04 de Novembro de 2018
[10] "Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture". Disponível em: https://sites.google.com/site/callforchapterssdmn/ Acessado em 03 de Novembro de 2018
[11] "What is Software-Defined WAN (or SD-WAN or SDWAN)?". Disponível em: https://www.sdxcentral.com/sd-wan/definitions/software-defined-sdn-wan/ Acessado em 03 de Novembro de 2018
"Este trabalho foi totalmente produzido pelos autores que declaram não terem violado os direitos autorais de terceiros, sejam eles pessoas físicas ou jurídicas. Havendo textos, tabelas e figuras transcritos de obras de terceiros com direitos autorais protegidos ou de domínio público tal como idéias e conceitos de terceiros, mesmo que sejam encontrados na Internet, os mesmos estão com os devidos créditos aos autores originais e estão incluídas apenas com o intuito de deixar o trabalho autocontido. O(s) autor(es) tem(êm) ciência dos Artigos 297 a 299 do Código Penal Brasileiro e também que o uso do artifício de copiar/colar texto de outras fontes e outras formas de plágio é um ato ilícito, condenável e passível de punição severa. No contexto da Universidade a punição não precisa se restringir à reprovação na disciplina e pode gerar um processo disciplinar que pode levar o(s) aluno(s) à suspensão;"