Redes Definidas por Software

UFRJ - EEL878 - Redes de Computadores I - Primeiro semestre de 2018

Resumo

Redes definidas por software é um paradigma de infraestrutura de redes que se destacou no meio acadêmico e nas indústrias do ramo nos últimos anos por ter maior simplicidade e flexibilidade do que a tecnologia atual. Neste trabalho definiremos o tema com mais detalhes, contextualizando o motivo do seu surgimento e explicando seu funcionamento e arquitetura. Será visto também diferentes aplicações da tecnologia, desafios na sua implantação e, por fim, uma conclusão junto à opinião final do grupo sobre o tema.

Alunos:

Gabriela Lemos Lúcidi Pinhão
Lucas Vieira Gama
Raimundo do Espírito Santo Costa

Professor:

Luis Henrique M. K. Costa

Direitos autorais:

"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;"

Introdução

Os protocolos utilizados atualmente para a construção de redes de computadores são complexos e de difícil gerenciamento. Se uma mudança de configuração é necessária, esta deve ser feita em cada componente da rede, fazendo uso de linguagem de baixo nível e seguindo as especificações de cada componente, que podem variar de acordo com o fabricante. Não é possível com a infraestrutura de redes atual configurar ou reconfigurar componentes automaticamente de acordo com a demanda de pacotes ou a partir de uma estratégia estabelecida. Tal inflexibilidade representa um entrave para a evolução da infraestrutura, tornando-se "engessada".

Nesse contexto, surgiram diversos paradigmas com o intuito de flexibilizar a infraestrutura de redes de computadores, dentre eles o de Redes Definidas por Software (SDN) que prevê a viabilização da programação de redes, possibilitando configuração automática, redução dos custos de manutenção e de operação destas. A tecnologia SDN baseia-se na separação da camada de dados e de controle que passam a ser controladas por softwares, transferindo poder e complexidade a nível de hardware para software.

Motivação

O surgimento das tecnologias de big data e machine learning impulsionaram o tratamento de conjunto de dados de volumes jamais imaginados. Elas impulsionaram também o surgimento de inúmeras aplicações de sistemas distribuídos fazendo comunicação por meio de redes de computadores. Com isso, a quantidade de tráfego vem aumentado consideravelmente e com arquitetura de redes TCP/IP, utilizada atualmente, é difícil e cara a adaptação e gerenciamento de redes para suprir tal demanda, que tende a aumentar cada vez mais.

Por outro lado, com a internet sendo essencial torna-se impossível colocá-la fora do ar para a troca da infraestrutura da rede. Dessa forma, a implantação de novas tecnologias no campo deve prever uma substituição gradual, sem a paralisação da infraestrutura existente.

O SVN surge como uma possível solução pois permitiria a configuração de redes por meio de aplicações programáveis sem necessidade de manuseio de hardware, barateando e flexibilizando a estrutura. Ao mesmo, estão sendo estudadas formas de implementar uma tecnologia híbrida onde a infraestrutura tradicional e a que faz uso de SDN funcionem em harmonia, sem necessidade de ruptura completa da primeira. Desta forma, a migração é gradual e, portanto, possível.

Definição

A SDN pode ser definida por quatro funcionalidades principais:

Separação do plano de dados do plano de controle: Na arquitetura atual os dois planos estão acoplados e são diferentes para cada nó da rede, atuando em conjunto na definição dos caminhos que os pacotes que chegam a tal nó podem seguir. Caso hajam mudanças a serem feitas, deve-se alterar a configuração dos planos de controle e dados daquele nó específico. Com a separação dos dois planos, o plano de controle pode ter uma visão completa de todos os nós da rede, podendo controlar a configuração de todos da mesma maneira, adequando o fluxo entre nós da maneira mais adequada dependendo demanda ou estratégia;

Visão e controle da rede centralizados: A camada de controle pode agora centralizar o conhecimento da configuração de todos os nós da rede e tem poder de alterá-los de forma uniforme e não mais específica para cada nó como na estrutura atual;

Criação de interfaces entre os dispositivos da camada de dados e de controle: Para que não haja contato direto entre as camadas, existe uma interface de comunicação chamada API (Application Programming Interface);

Programação da rede por aplicações externas: A camada de controle está também ligada a uma camada de aplicação, também por meio de API, que usam as informações das configurações dos nós para elaborar estratégia de rotas entre os nós da rede por meio de softwares. Posteriormente podem requerer à camada de controle mudanças na camada de dados.

Arquitetura

Componentes do sistema e funcionamento geral

O SVN atua em três planos, como ilustrado na figura 1: o plano de aplicação, plano de controle e plano de dados. No plano de controle fica o componente chave, o controlador, responsável por receber instruções do plano de aplicação e aplicar as mudanças necessárias no plano de dados para que esses sejam redirecionados. No plano de aplicação ficam os softwares responsáveis pelo gerenciamento da rede. No plano de dados fica o hardware necessário para o encaminhamento de dados.

Entre os planos existem APIs que interceptam a comunicação entre eles. A API Northbound é responsável pela comunicação entre o plano de aplicação e o plano de controle, oferecendo funções a serem chamadas pelas aplicações que realizam modificações específicas no plano de dados. A API Southbound é responsável pela comunicação do plano de dados com o plano de controle. O protocolo OpenFlow é uma das APIs Southbound mais utilizadas e será abordado seguir.

OpenFLow

O protocolo OpenFlow é um dos protocolos existentes e um dos principais responsáveis pela implementação atual de SDN. O desenvolvimento do OpenFlow teve início em 2007 e sua evolução tem recebido contribuições da academia e da indústria. O protocolo OpenFlow foi proposto inicialmente como uma alternativa para facilitar a inovação em ambientes universitários. O que evoluiu deste kernel inicial foi uma visão de que o OpenFlow poderia substituir completamente a funcionalidade dos protocolos da camada 2 e da camada 3 em switches e roteadores comerciais. Concebido originalmente por pesquisadores da Universidade de Stanford e da Universidade da Califórnia em Berkeley, o padrão tem sido mantido pela Open Networking Foundation (ONF3). A ONF é uma organização direcionada ao usuário, dedicada à promoção e adoção de SDN através do desenvolvimento de padrões abertos e que possui como membros algumas das principais empresas da área de tecnologia, tais como Google, Microsoft, Cisco, AT&T, Juniper, Oracle, dentre outras.

OpenFlow e outros protocolos de SDN têm gerado interesse devido ao grande controle que eles oferecem aos desenvolvedores de software de controle de rede. Ao criar uma interface normalizada, acessível pela rede para controlar o plano de dados de equipamentos de rede, a lógica do plano de controle pode ser movida de dispositivos de rede individuais para um controlador centralizado ou um grupo de controladores. Ao implementar a lógica de controle no controlador, mudanças de protocolo de rede e requisitos complexos de engenharia de tráfego podem ser ajustados reconfigurando, atualizando ou trocando o controlador ao invés de atualizar ou substituir o equipamento de rede.

O OpenFlow é um conjunto de protocolos e uma API, não um produto em si ou mesmo um único recurso de um produto. Colocado de outra forma, o controlador não faz nada sem um programa de aplicação (possivelmente mais de um), dando instruções sobre quais fluxos vão para quais elementos (por suas próprias razões).

O OpenFlow separa a rede em dois planos: o plano de controle, responsável pela execução dos algoritmos de controle da rede, e o plano de dados, responsável pelo encaminhamento e tratamento dos pacotes de rede em si. O OpenFlow se baseia em encaminhamento por fluxos, se aproveitando do fato de que grande parte dos fabricantes de comutadores e roteadores atuais implementam uma tabela de encaminhamento e coleta de estatísticas diretamente nos equipamentos.

OpenFlow define um protocolo-padrão para determinar as ações de encaminhamento de pacotes em dispositivos de rede, como, por exemplo, comutadores, roteadores e pontos de acesso sem fio. As regras e ações instaladas no hardware de rede são responsabilidade de um elemento externo, denominado controlador, que pode ser implementado em um servidor comum conforme figura 2.

A principal abstração utilizada na especificação OpenFlow é o conceito de fluxo. Um fluxo é constituído pela combinação de campos do cabeçalho do pacote a ser processado pelo dispositivo, conforme a Figura 3. As tuplas podem ser formadas por campos das camadas de enlace, de rede ou de transporte, segundo o modelo TCP/IP. Deve-se enfatizar que a abstração da tabela de fluxos ainda está sujeita a refinamentos, com o objetivo de oferecer uma melhor exposição dos recursos do hardware e, nesse caso, permitir a concatenação de várias tabelas já disponíveis, como, por exemplo, tabelas IP/Ethernet/MPLS. Nesse sentido, a contribuição mais importante do paradigma do OpenFlow é a generalização do plano de dados – qualquer modelo de encaminhamento de dados é baseado na tomada de decisão fundamentada em algum valor, ou combinação de valores, dos campos de cabeçalho dos pacotes pode ser suportado.

Composição dos Switches OpenFlow

Os switches OpenFlow devem possuir/suportar as seguintes características:

• Tabela de Fluxos;
• Canal Seguro;
• Protocolo OpenFlow.

A tabela de fluxos contém 12 campos que serão utilizados para a classificação de um fluxo, uma ação para cada fluxo e contadores. O canal seguro irá conectar o switch OpenFlow ao controlador e permitirá que os comandos passem por ele. Já o protocolo OpenFlow é o que será utilizado para essa comunicação. A especificação de um switch OpenFlow pode ser observada na figura 4.

Open vSwitch

OOpen Switch (OVS), é uma implementação de código aberto de um comutador multicamada virtual distribuído. O objetivo principal do Open vSwitch é fornecer uma pilha de comutação para ambientes de virtualização de hardware, enquanto suporta múltiplos protocolos e padrões usados ​​em redes de computadores. O código-fonte do projeto é distribuído sob os termos da licença apache 2.0.

Ele foi projetado para permitir a automação maciça de rede por meio de extensão programática, enquanto ainda suporta interfaces e protocolos de gerenciamento padrão (por exemplo, netflow, sflow, ipfix, rspan, cli, lacp, 802.1ag). Além disso, ele foi projetado para oferecer suporte à distribuição em vários servidores físicos, semelhante ao vNetwork da VMware vswitch distribuído ou ao nexus 1000v da cisco.

O Open vSwitch é usado em vários produtos e executado em muitos ambientes grandes de produção (alguns muito, muito grandes). Cada versão estável é executada por meio de um conjunto de regressão de centenas de testes no nível de sistema e milhares de testes unitários.

O OpenvSwitch foi projetado para permitir configuração e programação de forma automatizada. Ele integra com diversas plataformas e hypervisors. Dentro de ambientes virtualizados a taxa de mudanças é alta e um software como o OpenvSwitch se adapta dinamicamente e facilita o controle da rede.

Programas

O OpenVSwitch contém vários programas utilitários. Cada um é responsável por uma parte de sua arquitetura. Na tabela abaixo pode ser verificada uma breve descrição de cada utilitário.

O serviço

O OpenvSwitch pode ser controlado como um serviço normal dentro do sistema operacional. Essa administração depende do gerenciador de serviços do sistema operacional.

FlowVisor

Redes definidas por software, ao definirem uma forma flexível de se alterar a funcionalidade da rede, abriram espaço para que pesquisadores e desenvolvedores usassem a rede como ambiente de testes. Entretanto, ao se conectar os elementos de comutação de uma rede a um controlador único, a capacidade de se desenvolver e instalar novas aplicações na rede fica restrita ao responsável por aquele controlador. Mesmo que o acesso a esse elemento seja compartilhado entre diversos pesquisadores, ainda há a questão da garantia de não-interferência entre as diversas aplicações e a restrição de que todos devem utilizar a mesma interface, sem opções.

Os protocolos OpenFlow não fornecem diretamente o fatiamento da rede (um recurso atraente que permite a capacidade de dividir um elemento em grupos controlados separadamente ou uma rede em domínios administrativos separados). No entanto, ferramentas como o FlowVisor (que atua como um proxy transparente entre vários controladores e elementos) e implementações de fornecedores específicos (agentes que permitem a criação de vários interruptores com sessões separadas do controlador) tornam isso possível.

O FlowVisor não passa de um controlador OpenFlow que tem como principal característica atuar como um middleware entre os switches e os outros controladores OpenFlow. Todas as mensagens que são trocadas entre switches e o controlador são transmitidas por ele.

A sua principal função é dividir a rede entre os outros controladores OpenFlow de maneira a garantir o isolamento entre as divisões, ou seja, ele deve garantir que cada controlador só possa ter visão e controle sobre seu pedaço da rede. Essa divisão pode ser feita de diversas maneira como por exemplo utilizando os endereços IP ou portas TCP.

Ou seja, FlowVisor é um mecanismo de virtualização de redes OpenFlow. A virtualização é importante para permitir que em uma mesma infraestrutura física possam coexistir redes com diferentes mecanismos de encaminhamento, endereçamentos, entre outros. Assim, os recursos da infraestrutura necessitam ser divididos entre as diferentes fatias da rede. Um exemplo de aplicação de virtualização das redes OpenFlow é permitir, por exemplo, que diferentes tipos de experimentos sejam conduzidos ao mesmo tempo na mesma rede de computadores de uma universidade. Os recursos da infraestrutura divididos pelo FlowVisor são:

• Banda Passante: A banda passante de um enlace deve ser dividida entre as fatias da rede;
• Topologia: Cada fatia deverá possuir sua própria visão dos nós da rede e a conectividade entre eles;
• Tráfego: O tráfego de uma fatia não deve interferir na outra. Esse tráfego pode ser definido de várias formas como, por exemplo, todos os pacotes oriundos de um conjunto de endereços, todo o tráfego de um grupo de usuários ou algo mais específico como todo o tráfego HTTP;
• CPU dos elementos da rede: A CPU dos comutadores e roteadores da rede deverão ser divididas entre as fatias. Isso é importante, por exemplo, em casos onde os pacotes passam pelo chamado slow-path, como no caso de pacotes IP com opções, no qual a CPU do comutador necessita ser utilizada;
• Tabela de Encaminhamento: Devido à capacidade limitada dos comutadores para armazenarem regras de encaminhamento, há necessidade de controlar esses recursos entre as fatias.

A figura 6 mostra um exemplo de operação do Flowvisor:

A rede é dividida entre três controladores. Dois deles são para os experimentos de Alice e Bob e o outro controla o tráfego de produção. Bob realiza um experimento usando seu controlador que, por exemplo, atua como um balanceador de carga de tráfego HTTP. Nesse experimento o controlador dissemina tráfego para todos os servidores de um conjunto especificado previamente. As políticas da fatia da rede dada para o Bob são feitas de tal forma que o seu controlador só enxerga os fluxos provenientes de um determinado IP de origem. Devido à transparência do FlowVisor, porém, o controlador do Bob acredita que pode controlar os fluxos para todo tráfego HTTP vindo de qualquer IP de origem. Assim, o exemplo acima, quando o controlador do Bob envia uma mensagem para adicionar uma entrada na Tabela de Fluxos de um comutador, o FlowVisor intercepta essa mensagem (1). Após a interceptação, o FlowVisor consulta as políticas da fatia do Bob (2), e reescreve essa entrada para incluir apenas o tráfego oriundo do IP de origem permitido para Bob. Após isso envia uma mensagem com essa entrada para o comutador (3). Da mesma forma, as mensagens enviadas dos comutadores para o controlador do Bob são interceptadas pelo FlowVisor (4).

Programação dos elementos de rede

O conceito de programabilidade de rede está no cerne de um dos princípios fundamentais de redes definidas por software. O conceito de programabilidade pode existir ou ser um recurso de vários dispositivos de rede e componentes de software - e este não é um novo conceito, já que o gerenciamento de rede existe desde o início dos tempos para dispositivos em redes. O que difere agora é especificamente como esses dispositivos - reais ou virtuais - não são apenas gerenciados, mas também como interagem. Independentemente do alvo, o objetivo é torná-lo facilmente programável e facilitar um canal bidirecional de comunicação entre ele e o outro software comunicando-se com ele. Isso forma o que nós referimos como um loop de feedback fortemente acoplado entre esses elementos. Na verdade, esse conceito é bem diferente do paradigma tradicional de gerenciamento de rede, em que o gerente e o agente se comunicavam de maneira relativamente livre, com considerável atraso entre as operações - incluindo casos em que praticamente não existia feedback.

Para realizar esse novo paradigma de comunicação e interação, são necessárias interfaces programáticas bidirecionais fortemente acopladas. Essas interfaces também precisam ser prontamente e rapidamente implementadas em software, de modo a incentivar seu uso e implantação onipresente. As interfaces precisam fornecer recursos de auto-descrição para que os aplicativos possam aprender e compreender de maneira fácil e dinâmica as capacidades de um elemento de rede sem precisar ser recompilado. O efeito final será, então, interfaces com as quais se pode codificar com segurança e que são portáveis em diferentes plataformas de controladores.

A interface de gerenciamento

As interfaces de gerenciamento permitem que os operadores de rede gerenciem dispositivos de rede em suas redes. Essas interfaces geralmente fornecem ao operador uma visão operacional consistente de um dispositivo, incluindo sua configuração e status operacional. Uma interface de gerenciamento normalmente consiste em dois elementos principais: um protocolo e uma especificação de formato de mensagem. No caso do protocolo, isso descreve a sintaxe e a semântica associadas ao envio ou recebimento de mensagens específicas que o gerenciador ou elemento de rede gera. Essas mensagens geralmente contêm comandos, consultas ou respostas a consultas anteriores. Em alguns casos, essas mensagens podem ser emitidas sem uma consulta direta - como é o caso de eventos (notificações) que são emitidos de forma assíncrona em resposta a algum evento no elemento de rede. O outro elemento-chave de uma interface de gerenciamento é o formato da mensagem e o significado dessas mensagens. Algumas interfaces de gerenciamento definem um modelo de dados que pode ser usado como um diretório de informações disponíveis para a operadora de rede. Em alguns casos, eles também podem ser usados ​​para descrever como um gerente pode construir (ou ordenar) consultas ou comandos entre ele e o dispositivo. O modelo de dados também descreve tipicamente o relacionamento entre objetos gerenciáveis ​​dentro do sistema. Por exemplo, o nome do sistema pode ser mantido em um objeto chamado sysName e associado a outro objeto chamado sysUpTime, indicando o período de tempo que o sistema está sendo executado. Esses dois objetos seriam relacionados por estarem contidos no objeto pai chamado system, que representa o sistema inteiro.

A divisão da rede de aplicativos

Até recentemente, a maioria dos elementos de rede modernos (por exemplo, roteadores, switches ou firewalls) suportavam um pequeno conjunto de interfaces tradicionais que eram usadas para se comunicar com esses elementos. Estes tipicamente incluíam uma interface de linha de comando (CLI) proprietária, SNMP, CORBA e, mais recentemente, alguma forma de NETCONF. Esses idiomas têm alguns traços-chave em comum. Em primeiro lugar, eles são, em geral, de natureza muito estática e exigem um modelo e uma declaração de modelo de dados a priori. Na prática, isso significa que o código geralmente é gerado a partir dessas interfaces, que são criadas diretamente nas imagens de firmware executadas nos elementos de rede, bem como no software de gerenciamento (ou aplicativos).

Isso significava que as interfaces usadas para conversar com um elemento de rede tinham que ser pré-programadas em vez de serem aprendidas on-the-fly. Em segundo lugar, a sintaxe das linguagens usadas para definir a estrutura de mensagens e regras pelas quais os elementos devem manipular mensagens (ou seja, somente leitura e leitura-gravação) é, de certa forma, construída especificamente para essas interfaces de gerenciamento. Em terceiro lugar, esses protocolos usavam frequentemente codificações binárias, o que significa que, embora fossem compactos na conexão, eram difíceis de programar, depurar e representar de outra forma. Por fim, as práticas comuns em torno da escrita dos módulos sintáticos que descrevem o esquema de qualquer uma dessas interfaces eram freqüentemente não-hierárquicas, o que significa que era difícil navegar não apenas por aplicativos, mas também para humanos tentando descobrir o caminho do esquema.

Na maioria dos casos, um aplicativo que tinha permissão para ter qualquer tipo de discurso com um elemento de rede ou seus serviços era necessário para se comunicar usando um desses protocolos ou, mais comumente, precisava se comunicar por meio de um sistema de gerenciamento de elementos de gerenciamento de rede (EMS). O EMS atuou como um proxy entre os elementos de rede e os aplicativos. Infelizmente, o EMS (ou NMS) geralmente não expunha os elementos de rede ou os serviços que eles forneciam em qualquer tipo de aplicativo amigável, o que significa que codificar para essas interfaces e paradigmas era complicado e resultou em longos períodos de tempo entre um aplicativo sinalizando sua desejo de fazer algo e que algo realmente está acontecendo. Isso é, de fato, o que chamamos de divisão da rede de aplicativos, ilustrada na figura 7.

Para isso, uma resposta é usar interfaces que sejam interfaces de aplicações amigáveis RESTful (transferência representacional de estado). Acontece que essas interfaces são geralmente definidas usando abordagens modernas, como JSON (JavaScript Object Notation). O JSON resolve muitos dos defeitos que acabamos de descrever porque seu esquema é definido usando XML legível por humanos, é auto-referencial, é hierárquico e é algo que é facilmente incorporado em aplicativos Java - a linguagem de programação de aplicativos mais comum da última década.

As interfaces para programação dos dispositivos da rede mais comuns são:

• Interfaces de linha de comando (CLI);
• Protocolos de configuração de rede: SNMP e NETCONF.

Interfaces programáticas modernas

Agora que descrevemos as interfaces de gerenciamento mais comuns, vamos passar a discussão para interfaces e conceitos de gerenciamento modernos. Essas novas interfaces e conceitos são aqueles que permitem e incentivam a capacidade de programação da rede no melhor sentido. Para esse fim, essas interfaces exibem a maior parte, senão todos, dos principais atributos das interfaces mais comuns: bidirecional, fácil de usar e autodescritivo. Eles também incorporam modelos de dados robustos que podem se traduzir em comportamento orientado a dados e implementação rápida e, claro, são facilmente desenvolvidos pela comunidade de desenvolvedores. Vamos enumerar as principais delas mas sem entrar em detalhes do seu funcionamento:

• Publish and Subscribe Interfaces: Ou simplesmente pub-sub, como é mais comumente conhecido, são um padrão de mensagens através do qual os remetentes de mensagens (chamados publicadores) enviam mensagens para os receptores (chamados assinantes). Os remetentes não programam as mensagens para serem enviadas diretamente para destinatários específicos, mas sim para caracterizar mensagens publicadas em classes. Isso é feito sem o conhecimento expresso de quais assinantes, se houver, podem existir a qualquer momento;
• XMPP: O protocolo XMPP (Extensible Messaging and Presence Protocol) é um exemplo de um protocolo pub-sub e foi usado para implementar vários sistemas de publicação de assinaturas. XMPP é um protocolo de comunicação baseado em XML [Extensible Markup Language]. O protocolo pode ser usado para fornecer mensagens instantâneas quase em tempo real, informações de presença ou praticamente qualquer informação realmente que precise ser estendida a um grupo de assinaturas. Ele foi projetado para ser extensível, como o próprio nome sugere;
• Google’s Protocol Buffers: Os protocolos de buffers são uma linguagem neutra da plataforma do Google, mecanismo extensível para serializar dados estruturados. O Google inventou os protocolos de buffers como um refinamento das deficiências encontradas por seus codificadores em ambos XML e JSON;
• Thrift: É uma linguagem de definição de interface usada para definir e criar serviços para várias linguagens. Como os protocolos de buffers, ele também é usado como uma estrutura de chamada de procedimento remoto (RPC). Como os protocolos de buffers, o Thrift foi desenvolvido para atender às crescentes necessidades de um provedor de serviços de conteúdo de aplicativos - o Facebook. Na época de sua criação, o Facebook operava data centers em grande escala e encontrava problemas semelhantes aos que o Google enfrentou alguns anos antes. O Thrift é escrito em C ++, mas seu compilador pode criar código para várias linguagens. Como os protocolo de buffers, o Thrift combina um mecanismo de geração de código para criar serviços com suporte à linguagem de multiprogramação, embora no espírito do ambiente de desenvolvimento muito mais flexível do Facebook, o Thrift suporta uma ampla variedade de linguagens geradas, incluindo C ++, Erlang, Go, Haskell, Perl, Cappuccino, Python, C #, Perl, Ruby, Smalltalk, Node.js e PHP;
• JSON: JavaScript Object Notation, ou JSON, como é mais comumente conhecido, é um formato leve de troca de dados. Um dos principais apelos do JSON é que, sendo baseado em XML, é fácil para humanos ler e escrever. Ao mesmo tempo, é relativamente fácil para as máquinas analisar e gerar. JSON é um formato de texto completamente independente do idioma, mas usa convenções que são familiares aos programadores da família C de linguagens, incluindo C, C ++, C #, Java, JavaScript, Perl e Python. São essas propriedades que tornam o JSON uma linguagem de intercâmbio de dados muito atraente e que provou ser excelente em termos de uso para construir APIs para controladores e aplicativos SDN.

Aplicações

Gerenciamento de Redes

Um das principais aspectos da SDN é a centralização da configuração da rede, que proporciona uma visão global do ambiente e que permitiria um monitoramento mais claro dos fluxos de interesse. Este monitoramento global permite, por exemplo, a aplicação de técnicas de inteligência artifical para a detecção de anomalias na rede, como um ataque de negação de serviço. Há projetos, por exemplo, para simplificar o processo de administração de redes OpenFlow, através de interfaces de controle baseadas em uma arquitetura de serviços.

Pela automatização oferecida por Redes Definidas por Software, permite-se a criação de abstrações, em diferentes camadas lógicas, proporcionando uma flexibilidade da rede. Tanto em redes locais, LAN (Local Area Networking), como em SD-WAN (Software Defined Wide Area Networking), que é o uso de uma plataforma de software para controlar o acesso, através de múltiplos tipos de conexão, para escritórios remotos. Além disso, em IoT (Internet of Things), o crescente número de dispositivos gera uma avalanche de tráfego na rede, onde a SDN poderia ajudar a analisar os fluxos, além de priorizar ou alterar rotas para maior eficiência.

QoS (Quality of Service)

Com o novo paradigma das SDNs e a configuração dinâmica proporcionada por esta, muitos mecanismos de qualidade de serviço têm sido pesquisados. Aplicações com o objetivo de garantir e melhorar a qualidade de serviço das redes de computadores se encaixam muito bem. Por exemplo, seria possível definir em um único passo as regras de qualidade de serviço para toda uma rede composta de diferentes dispositivos, definindo dinamicamente o nível de serviço para diferentes tipos de tráfegos.

Apesar disso, ainda faltam testes QoS a nível de mercado com SDNs, é o que apontam engenheiros de empresas de primeira linha em redes de computadores, podendo notar que a taxa de adoção de SDNs em ISPs é muito impactada pela falta de pesquisa de qualidade de serviço. Dado que QoS é um tópico relativamente novo, a pesquisa é escassa. Testes comparativos entre redes convencionais e SDNs demonstram desempenho similar, com pequenas perdas de QoS da arquitetura SDN, devido a latência introduzida na verificação da tabela de fluxo, além de limitações de hardware do dispositivo que a armazena.

Neste teste, ilustrado na figura 8, foi usado um controlador de redes SDN chamado Floodlight. Na imagem, podemos ver um vídeo distorcido, devido a falta de prioridade do tráfego de vídeos sobre o tráfego de dados. Após adicionado o módulo de QoS ao controlador, temos a imagem seguinte, sem distorções.

Controle de Acesso

A arquitetura permite o controle de acesso através do tratamento do pacote para controle de fluxo que se dá no controlador de SDNs, permitindo-a por exemplo verificar o protocolo utilizado, a origem e destino do pacote, até mesmo identificar o usuário, e assim podendo adotar uma rota para aquele fluxo específico. Assim, pode-se criar múltiplos filtros em cima do controlador com objetivos variados, alterar tráficos de usuários, isolar pontos, inspeção de pacotes, etc.

Redes Domiciliares

Redes domiciliares também são auxiliadas por SDNs. É um grande gasto para a indústria, uma vez que o usuário comum precisa manter uma rede de computador, porém não possui conhecimento técnico para tal configuração. Esse desafio pode ser solucionado tanto através de aumento de interação com o usuário, assim como desenvolvimento de novas soluções de automação das configurações dos dispositivos. SDN e NFV oferecem uma nova solução para o problema de interfaces domiciliares complexas: mover a interface para a nuvem.

Uma possível solução é usar o protocolo OpenFlow para converter os pontos domésticos em switches OpenFlow, como ilustrado na figura 9. Assim, os operadores de rede são capazes de controlar o fluxo sobre toda a rede. Esta solução conecta os dispositivos na rede local e roteia o tráfego para a interface WAN, e por último o provedor de serviço e a internet. BRGs (Bridged Residential Gateways) são dispositivos no domicílio, que podem se comunicar com o gateway virtual (vG) localizado na WAN, que tem um subconjunto de funcionalidades do gateway doméstico. O gateway virtual é uma parte lógica localizada em um ou mais nós que pode ser na rede do provedor de serviço, ou na nuvem.

Economia de Energia

Economizar energia é um interesse constante em sistemas de computação. Com a visão global da rede, é possível identificar as rodas mais utilizadas, assim como as subutilizadas, reduzir a taxa de transmissão de enlaces, ou até mesmo desligar pontos, e seus dispositivos, da rede para a economia de energia torna-se uma alternativa interessante. É possível também a redefinição de rotas de tráfego, desvio de rotas e afins, para o melhor aproveitamento da vazão da rede.

Desafios

Uma pesquisa foi conduzida em 2016, onde 50 engenheiros de empresas de primeira linha em redes de computadores, e o resultado foi o seguinte:

Performance

Um desafio da arquitetura SDN é a eficiência da rede, que agora possui camadas de processamento distintas. Ao aumentar a flexibilidade para novas funcionalidades e requisitos, adiciona-se camadas de processamento necessário, diminuindo a vazão e tempo de resposta. Consideramos esta flexibilidade a mudanças como a flexibilidade da arquitetura, enquanto a vazão e tempo de resposta como a performance da rede. Nesse sentido, elas são inversamente relacionadas.

Ainda é um desafio configurar redes com velocidades acima de 100 Gb/s. Na figura 11 é apresentado a relação de flexibilidade com a performance alcançada, onde é possível perceber que diminui-se a flexibilidade para aumentar a performance, substituindo unidades de processamento mais genéricas, como CPUs, por hardware cada vez mais dedicado, chegando a ASSPs e ASICs.

Arquiteturas em que os controladores são processadores de objetivo genérico (CPUs/GPPs) possuem maior flexibilidade e agilidade a mudanças, além da maior facilidade de implementação, através de linguagens de alto nível. Porém essa camada de abstração apresenta a sobrecarga de processamento, limitando esse modelo a performances de dezenas de gigabits por segundo, com o uso de técnicas de balanceamento de carga.

Processadores de fluxo de rede (NPU/NFP) são unidades de processamento com adaptações em hardware e em interfaces, aumentando sua performance e diminuindo a dissipação de calor. Entretanto exigem um conhecimento específico de sua arquitetura e comandos, para o melhor aproveitamento de seu processamento paralelo. Arquiteturas com NPUs no estado da arte conseguem atingir acima de 200 Gb/s por dispositivo.

ASSPs (Application-specific standard products) são hardwares especializados desenvolvidos para suportar grandes volumes de dados. Nos últimos anos foram desenvolvidos ASSPs com o foco em SDNs, suportando por exemplo OpenFlow, e atingindo taxas acima de 500 GB/s por segundo.

Finalmente, considerando a flexibilidade desejada versus a performance exigida, arquiteturas podem ser mistas. Por exemplo, com CPUs, NFPs e ASSPs, podemos atingir alta performance para o fluxo comum, e flexibilidade para novos fluxos de roteamento.

Escalabilidade

Escalabilidade da rede SDN pode ser dividido em escalabilidade do controlador e escalabilidade da rede. Focamos no problema introduzido pelo controlador. O design de SDNs apresenta uma parte lógica, o controlador centralizado, que fisicamente, porém, pode estar dividido em diferentes localizações, distribuídos em clusters por exemplo, para atingir uma escalabilidade desejada. Os controladores assim precisam de sincronização entre eles, criando complexidades e custos extras a rede. Há soluções desenvolvidas para tal problema, como o Hyperflow. Hyperflow é um aplicação de controlador que trabalha em cima do controlador NOX e funciona com a propagação de eventos. Ele publica eventos seletivamente para todos os controladores, que atualizam suas tabelas de estado / tabelas de fluxo, mantendo uma consistência entre a rede de controladores.

Segurança

A arquitetura SDN retorna com alguns problemas de segurança que eram mitigados pela arquitetura antiga. Com dispositivos de rede proprietário dos fabricantes e de configuração diferente de acordo com a empresa, antes, um ataque que explorava uma vulnerabilidade de um modelo afetava apenas a parte da rede composta pelos respectivos dispositivos. Agora com a alta configuração provida por um modelo centralizado, de interface aberta e conhecida, torna-se extremamente sensível, onde um ataque pode comprometer a rede como um todo.

Potenciais vulnerabilidades podem ser existir, por exemplo, pela camada de autenticação e autorização, pois o sistema pode ser controlado por diferentes organizações que têm acesso a rede. Diferentes níveis de acesso são necessários, pois diferentes agentes podem interagir com a configuração da rede. Além disso, por se tratar de padrões abertos e conhecidos, a fim de facilitar a integração por diferentes fabricantes, permite que atacantes conheçam toda a arquitetura e comandos. Uma vez invadida, o atacante torna-se capaz rapidamente e facilmente ter controle, podendo manipular a rede, os nós, e até usuários individuais.

Outra potencial vulnerabilidade se origina da centralização do controle da rede. Nesse nó está sujeito a ataques, por exemplo, de negação de serviço (DOS/DDOS). Pela arquitetura da SDN, quando um novo fluxo não encontrado na tabela é recebido, há duas opções, enviar o pacote completo ou apenas o cabeçalho para o controlador resolver o fluxo. Enviar o fluxo completo sobrecarrega esse canal, podendo congestionar o mesmo e comprometer a performance da rede. Caso seja enviado somente o cabeçalho, o restante do pacote precisa ser armazenado em um buffer. Este, por sua vez, é custoso e limitado, podendo ser consumido por completo, acarretando na perda de pacotes.

Conclusões

Neste trabalho buscou-se apresentar os conceitos da arquitetura de redes SDN, seu funcionamento, assim como suas aplicações em redes de computadores e os desafios desta tecnologia.

Com este trabalho, notamos que SDNs impactam consideravelmente redes convencionais, pois torna os dispositivos tradicionais incompatíveis, porém a longo prazo diminui a necessidade de intervenção física em dispositivos individuais, barateando os custos de manutenção. Além de outras vantagens citadas nas aplicações, que podem baixar ainda mais as despesas, tornando esta uma tecnologia extremamente atrativa. Seu impacto também é sobre qualquer rede de computador, fazendo com que o público alvo dessas soluções seja um mercado de bilhões de dólares, e novos dispositivos vêm sendo lançados constantemente.

Entretanto, esta tecnologia ainda se encontra em amadurecimento, carecendo de grandes casos de uso para a garantia de qualidade e o aquecimento do mercado, para uma migração de tecnologia por parte dos grandes operadores de rede.

Perguntas

1- Porque a infraestrutura de rede atual é considerada "engessada"? Como a tecnologia SDN visa flexibilizá-la?

Não é possível com a infraestrutura de redes atual configurar ou reconfigurar componentes automaticamente. Qualquer simples mudança requer o uso de linguagem de baixo nível e o conhecimento das especificações de cada componente da rede, que pode variar de acordo com o fabricante.

Nesse contexto, surge o paradigma de Redes Definidas por Software (SDN) que prevê a viabilização da programação de redes, possibilitando configuração automática e redução dos custos de manutenção e de operação destas.

2- Quais os componentes principais da tecnologia SDN? Quais as funções de cada plano?

O SVN atua em três planos: o plano de aplicação, plano de controle e plano de dados. No plano de controle fica o componente chave, o controlador, responsável por receber instruções do plano de aplicação e aplicar as mudanças necessárias no plano de dados para que esses sejam redirecionados. No plano de aplicação ficam os softwares responsáveis pelo gerenciamento da rede. No plano de dados fica o hardware necessário para o encaminhamento de dados. Entre os planos, existem APIs, chamadas API Northbound e API Southbound, responsáveis por facilitar a comunicação entre eles.

3- Explique como ocorre o encaminhamento de pacotes no protocolo OpenFLow.

O protocolo OpenFlow se baseia no conceito de fluxos. Um fluxo é constituído pela combinação de campos do cabeçalho do pacote a ser processado pelo dispositivo. Nesse sentido, a contribuição mais importante do paradigma do OpenFlow é a generalização do plano de dados – qualquer modelo de encaminhamento de dados é baseado na tomada de decisão fundamentada em algum valor, ou combinação de valores, dos campos de cabeçalho dos pacotes. Dependendo de como está configurado o controlador uma série de ações podem ser tomadas.

4- O que é virtualização de rede e por que o FLowVisor é necessário?

Virtualização consiste em abstrair e compartilhar uma estrutura física a uma virtual, possibilitando que múltiplas plataformas virtuais rodem sobre uma única estrutura física. Os protocolos OpenFlow não fornecem diretamente o fatiamento da rede (um recurso atraente que permite a capacidade de dividir um elemento em grupos controlados separadamente ou uma rede em domínios administrativos separados). A ferramenta FlowVisor surge para suprir esta necessidade atuando como um proxy transparente entre vários controladores e elementos.

5- Por que a arquitetura SDN é mais insegura do que arquiteturas de rede tradicionais?

Porque o controlador, parte lógica que define o comportamento dos fluxos da rede, é centralizado, tornando-se um ponto único de falha da rede inteira.

Bibliografia

[1] B. Fraser et al., “Are We Ready for SDN? Implementation Challenges for Software-Defined Networks,” IEEE Communications Magazine, Julho, 2013. [Online]. Disponível em: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6553676. Acessado em: Maio, 30, 2018.

[2] D. Kreutz et al., “Towards Secure and Dependable Software-Defined Networks,” ACM New York, Agosto, 2013. [Online]. Disponível: https://www.ietf.org/proceedings/87/slides/slides-87-sdnrg-2.pdf. Acessado em: Maio, 30, 2018.

[3] D. Meyer et al., “Software-Defined Networking (SDN): Layers and Architecture Terminology,” Internet Research Task Force, Janeiro, 2015. [Online]. Disponível em: https://www.rfc-editor.org/rfc/pdfrfc/rfc7426.txt.pdf. Acessado em: Maio, 30, 2018.

[4] A. Tootoonchian et al., “On Controller Performance in Software-Defined Networks,” The Advanced Computer Systems Association, April, 2012. [Online]. Disponível em: https://www.usenix.org/system/files/conference/hot-ice12/hotice12-final33_0.pdf. Acessado em: Maio, 30, 2018.

[5] G. Gu1 et al., “Modular Composable Security Services for Software-Defined Networks,” ISOC Network and Distributed System Security Symposium, April, 2013. [Online]. Disponível em: http://www.csl.sri.com/users/vinod/papers/fresco.pdf. Acessado em: Maio, 30, 2018.

[6] M. Menth et al., “Software-Defined Networking Using OpenFlow: Protocols, Applications and Architectural Design Choices,” Future Internet, April, 2014. [Online]. Disponível em: http://www.mdpi.com/1999-5903/6/2/302. Acessado em: Maio, 30, 2018.

[7] M. Dillon, T. Winters, “Virtualization of home network gateways”, IEEE Computer, Vol. 47, 2014, p. 62 - 65, Acessado em: Junho, 03, 2018. Disponível em: https://ieeexplore.ieee.org/abstract/document/6965269/. Acessado em: Maio, 30, 2018.

[8] D. D’souza, K. P. Sundharan, S. Lokanath, V. Mittal, “Improving QoS in a Software-Defined Network”, Capstone Research Paper, April, 2016, Disponível em: https://www.colorado.edu/itp/sites/default/files/attached-files/70129-130943_-_derrick_dsouza_-_apr_25_2016_859_pm_-_team_5_improving_qos_in_sdn_redo.pdf. Acessado em: Junho, 3, 2018.

[9] B. Butler, “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: Junho, 03, 2018.

[10] D. Guedes et al., “Redes Definidas 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: http://homepages.dcc.ufmg.br/~mmvieira/cc/papers/minicurso-sdn.pdf. Acessado em: Maio, 30, 2018.

[11] A. Janael Pinheiro et al., “Engenharia de Tráfego em Redes Definidas por Software,” Minicurso 3 do XXXIV Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, p.101-150, Junho, 2016. [Online]. Disponível em: http://www.sbrc2016.ufba.br/downloads/anais/MinicursosSBRC2016.pdf. Acessado em: Maio, 30, 2018.

[12] T. D. Nadeau e K. Gray, “SDN: Software Defined Networks: An Authoritative Review of Network Programmability Technologies,” O’Reilly Media, vol. 1, 2013.

[13] R. K. Sundararajan, “A Definitive Guide to Software Defined Networking (SDN),” Kloudspun Press, vol. 1, 2013.

[14] V. Shukla, “Introduction to Software Defined Networking - OpenFlow & VxLAN,” CreateSpace Independent Publishing Platform, vol. 1, 2013.