sexta-feira, 12 de julho de 2013

Paradigma SDN de Redes Programáveis

Olá Pessoal.

Um tema ainda recente na área de redes de computadores e que tem se destacado de maneira crescente nos últimos anos, inclusive com a adoção de algumas soluções comerciais por parte das principais empresas fabricantes de dispositivos de redes, é um novo paradigma de controle da infraestrutura conhecido como SDN (acrônimo de Software-Defined Network).

O termo surgiu em 2005 decorrente de pesquisas originalmente desenvolvidas pela Universidade de Stanford. O principal argumento favorável à SDN é que essa abordagem viabiliza que os serviços em execução na infraestrutura de rede podem ser gerenciados mais facilmente e com grande flexibilidade. Qual seria a idéia principal dessa presunção? É isso que vou tentar elucidar de maneira objetiva nesse artigo...

Atualmente na arquitetura dos principais dispositivos de redes (hardware), a exemplo de roteadores e switches, é comum organizarmos a disposição dos seus componentes eletrônicos em dois planos lógicos que são conhecidos como: 

  1. Plano de Dados ou Encaminhamento 
  2. Plano de Controle ou Gerência

O motivo de fazê-lo é garantir máximo desempenho à principal tarefa desses dispositivos: o encaminhamento de pacotes entre suas interfaces. No entanto o encaminhamento não pode ocorrer por si só sem informações de controle que determinem a inteligência dessas ações. 

Como a tarefa de encaminhamento de pacotes entre interfaces é bastante direta e objetiva, então sua implementação faz parte do plano de encaminhamento. Já a implementação da inteligência que diz respeito à gerência, configurações e protocolos dos dispositivos faz parte do plano de controle. 

Para entender melhor tudo isso vamos pegar como exemplo um roteador. Sabemos que o processo de roteamento, seja estático ou dinâmico, somente é possível porque os roteadores formam uma tabela de roteamento com informações que são consultadas para determinar o destino dos pacotes, o que torna possível encaminhá-los para suas respectivas interfaces de saída que devem alcançar o destino previsto.

A descrição acima é verdadeira, mas muito simplista. Na realidade existem memórias eletrônicas na arquitetura dos roteadores que armazenam algumas estruturas de dados que são utilizadas em variados contextos. Então vamos detalhar um pouco mais essas estruturas, mas tenham em mente que o exemplo aqui trazido é generalista e diferentes fabricantes podem implementar essas estruturas de maneira particular em seus equipamentos! Observem na figura abaixo os principais componentes de um roteador:




É no plano de controle que fica armazenada uma estrutura de dados denominada RIB (Routing Information Base). Essa estrutura é reponsável por armazenar todas as informações de vizinhança entre os roteadores e todas as rotas conhecidas até um determinado destino, seja ela a melhor ou não - simplesmente todas as rotas possíveis estão armazenadas nessa estrutura. É com base nessas estruturas que agem os principais protocolos de roteamento, seja para adicionar, modificar, remover ou consultar seu conteúdo. É de se imaginar que essa estrutura normalmente não é pequena e que esse processo de implementar a inteligência da rede não é simples porque envolve a ação de algoritmos que podem ser bem complexos.

Para otimizar o desempenho de encaminhamento dos roteadores existe outra estrutura de dados no plano de encaminhamento que é denominada FIB (Forwarding Information Base), essa sim mais próxima da tradicional tabela de roteamento que consultamos frequentemente no cotidiano. A FIB é uma estrutura bem mais simples que armazena somente a melhor rota para cada destino, ou algumas melhores dependendo da inteligência de roteamento. Normalmente essa estrutura é implementada através de tabelas hash para torná-la menor e agilizar o processo de busca de informação (lookup). 

Ou seja, a FIB (plano de encaminhamento) é gerada a partir da RIB (plano de controle). Dessa forma a operação do plano de encaminhamento ganha um certo grau de independência dos processos em execução no plano de controle e os dispositivos de rede podem fazer um lookup mais rápido e eficiente, o que reflete no desempenho do encaminhamento de pacotes. Em síntese, o plano de encaminhamento se limita a receber os pacotes, buscar uma correspondência na FIB e fazer o encaminhamento dos pacotes se houver essa correspondência. Mais uma vez reforço que essa descrição não é uma regra e pode variar na implantação de diferentes dispositivos e de diferentes fabricantes!

O paradigma SDN propõe uma ruptura nesse modelo tradicional, através do desacoplamento ainda maior entre os planos de controle e de encaminhamento. Assim passam a existir novos elementos na rede que ficam "exclusivamente" responsáveis pelo controle (inteligência), denominados controladores. E mais, esses controladores são programáveis via software, o que permite que toda a rede seja gerenciada e até mesmo remodelada com base em suas necessidades reais. A figura abaixo ilustra essa proposta:


Ao fazê-lo os dispositivos da infraestrutura tornam-se eletronicamente bastante simplificados porque seu foco passa a ser a tarefa de encaminhamento dos pacotes (plano de encaminhamento), desde que haja interfaces programáveis via software (API) que possam se comunicar com os controladores externos. Existem algumas propostas de padronização dessas APIs, mas sem dúvidas a mais conhecida delas é o OpenFlow que, a cada dia, passa a ser aderido por mais empresas fabricantes de dispositivos de redes.

Embora SDN seja o nome consagrado na academia (e isso não deve mudar), eu particularmente não acho que o nome Software-Defined Network seja o mais adequado, visto que atualmente é comum a implementação dos planos através de software na arquitetura interna (localmente) dos dispositivos. Ao meu ver a mudança mais visível na SDN é a idéia da controladora externa, algo que na realidade não chega a ser uma grande novidade se tomarmos como exemplo as controladoras de várias soluções wireless existentes no mercado e que ficam responsáveis pelo gerenciamento centralizado dos APs.

O grande diferencial do SDN, na realidade, é a proposta da utilização de interfaces programáveis (APIs) entre os dispositivos e a(s) controladora(s), o que traz potencial para que TODO o modo de operação das redes seja repensado e reescrito! Um passo além, o esforço de padronização dessas interfaces traz um potencial ainda maior para esse paradigma. 

Há uma vertente de pesquisadores que entende que esse novo paradigma assusta as empresas fabricantes de dispositivos de redes porque equipamentos com hardware convencional podem ser utilizados como controladora e por isso essas empresas perderiam mercado para novos entrantes. São muitos os que defendem essa idéia...

Eu tenho minhas dúvidas e diria até que não concordo com isso, pelo menos não dessa maneira radical. Penso assim porque é necessário reconhecer que uma das características mais relevantes na disputa entre as empresas fabricantes de dispositivos de rede está justamente na qualidade e desempenho do hardware desenvolvido - e isso não deve mudar, principalmente quando pensamos em ambientes onde há grande fluxo de dados.

Entendam que essa visão não é contrária ao paradigma SDN, afinal existe um grande potencial em "casar" o desenvolvimento de hardware de qualidade aliado com interfaces programáveis, principalmente no que diz respeito à possibilidade de as empresas criarem controladoras próprias e APIs que ofereçam flexibilidade para ambientes específicos, a exemplo de Data-Centers,  algo que a Cisco (e outros fabricantes) já oferece. Quem tiver mais interesse na solução SDN da Cisco, saiba que ela é denominada ONE (Open Network Environment). Vejam detalhes no link abaixo:


Essa é mais um daqueles tópicos recentes de pesquisa na área de redes em que é muito difícil assegurar os rumos do seu futuro comercial...

Abraço.

Samuel.

4 comentários:

  1. Belo artigo Samuel, continues assim, forte abraço.

    ResponderExcluir
  2. Ouvi comentários sobre isso mas não sabia o que era. Show de bola !

    ResponderExcluir
  3. Prezado Prof. Samuel,

    A própria Internet precisou de um padrão definido (TCP/IP) para interoperabilidade independente de fabricante; flexibilizando o crescimento da mesma e abrindo opões para as redes convergentes. Se a Cisco adotar um padrão próprio de APIs e os demais fabricantes outros padrões, há possibilidade de regredir a tempos remotos? Como estão planejando ambientes mistos e APIs divergentes para interoperarem?

    ResponderExcluir