Arquitetura e Protocolo OpenFlow
Arquitetura e Protocolo OpenFlow
Há algum tempo observa-se o surgimento da necessidade de maior abertura e flexibilidade dos equipamentos de rede, especialmente com o propósito de pesquisa e inovação. Os roteadores atuais implementam uma arquitetura composta por uma camada de software fechada, que é executada em um hardware proprietário. Esse modelo resulta em soluções de alto custo, dificulta a inserção de novas funcionalidades e inviabiliza a experimentação de novas ideias. Com o avanço da padronização do protocolo OpenFlow para programar o plano de encaminhamento dos equipamentos de redes de pacotes, o conceito de redes programadas por software traz um novo paradigma de inovação cujo potencial disruptivo assemelha-se ao da introdução de sistemas operacionais em computadores e, mas recentemente, em dispositivos móveis.
- Christian Esteve Rothenberg
A Arquitetura de Roteamento
Uma análise da arquitetura atual dos roteadores (Figura 1) permite observar que se trata de um modelo formado basicamente por duas camadas bem distintas: o software de controle e o hardware dedicado ao encaminhamento de pacotes. O primeiro, encarregado de tomar as decisões de roteamento, transfere essas decisões para o plano de encaminhamento através de uma API proprietária. A única interação da gerência com o dispositivo ocorre através de interfaces de configuração (Web, SNMP, CLI, por exemplo), limitando o uso dos dispositivos às funcionalidades programadas pelo fabricante.
É coerente pensar que se a arquitetura é, atualmente, composta por duas camadas autocontidas, elas não precisam estar fechadas em um mesmo equipamento. Para isso, basta que exista uma forma padrão de se programar o dispositivo de rede remotamente, permitindo que a camada de controle possa ser movida para um servidor dedicado e com alta capacidade de processamento. Desse modo, mantém-se o alto desempenho no encaminhamento de pacotes em hardware aliado à flexibilidade de se inserir, remover e especializar aplicações em software por meio de um protocolo aberto para programação da lógica do equipamento (Figura 1). Com esse propósito, nasceu o consórcio OpenFlow, dando origem ao conceito de Software Defined Networking – as redes definidas por software.
Figura 1O OpenFlow
O OpenFlow foi proposto pela Universidade de Stanford para atender à demanda de validação de novas propostas de arquiteturas e protocolos de rede sobre equipamentos comerciais. 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.
Figura 2A 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 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.
Figura 3De forma pragmática, a especificação OpenFlow procura reutilizar as funcionalidades do hardware existente (por exemplo, Access Control List – ACL em switches e roteadores para implementar serviços como NAT, firewall e VLANs) através da definição de um conjunto simples de regras e das ações associadas: encaminhar, descartar, enviar para o controlador, reescrever campos do cabeçalho, etc.
Os Componentes
Basicamente, uma rede programável com OpenFlow consiste em equipamentos de rede habilitados para que o estado das tabelas de fluxos possa ser instalado através de um canal seguro, conforme as decisões de um controlador em software.
A Tabela de fluxos
Cada entrada na tabela de fluxos do hardware de rede consiste em regra, ações e contadores. A regra é formada com base na definição do valor de um ou mais campos do cabeçalho do pacote. Associa-se a ela um conjunto de ações que definem o modo como os pacotes devem ser processados e para onde devem ser encaminhados. Os contadores são utilizados para manter estatísticas de utilização e para remover fluxos inativos. As entradas da tabela de fluxos podem ser interpretadas como decisões em cache (hardware) do plano de controle (software), sendo, portanto, a mínima unidade de informação no plano de dados da rede.
O Canal seguro
Para que a rede não sofra ataques de elementos mal-intencionados, o canal seguro garante confiabilidade na troca de informações entre o switch e o controlador. A interface de acesso recomendada é o protocolo SSL (Secure Socket Layer). Interfaces alternativas (passivas ou ativas) incluem TCP e pcap (packet capture), e são especialmente úteis em ambientes virtuais e experimentais pela simplicidade de utilização, pois não necessitam de chaves criptográficas.
O Protocolo OpenFlow
Protocolo aberto para comunicação que usa uma interface externa, definida pelo OpenFlow para a troca de mensagens entre os equipamentos de rede e os controladores. Essas mensagens podem ser simétricas (hello, echo vendor), assíncronas (packet in, flow removed, port status, error) ou, ainda, iniciadas pelo controlador (features, configuration, modify state, send packet, barrier).
O Controlador
É o software responsável por tomar decisões e adicionar e remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. O controlador exerce a função de uma camada de abstração da infraestrutura física, facilitando a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede. Esse modelo assemelha-se a outros sistemas de software que proveem abstração do hardware e funcionalidade reutilizável.
Dessa forma, o controlador OpenFlow atua como um sistema operacional (SO) para gerenciamento e controle das redes, e oferece uma plataforma com base na reutilização de componentes e na definição de níveis de abstração (comandos da API). Contudo, novas aplicações de rede podem ser desenvolvidas rapidamente. A programabilidade do controlador permite a evolução em paralelo das tecnologias nos planos de dados e as inovações na lógica das aplicações de controle.
A Figura 4 mostra uma abstração de uma rede com OpenFlow e o controlador NOX executando inúmeras aplicações que necessitam de uma visão do estado da rede. Essa visão pode ser armazenada, por exemplo, em um simples banco de dados executado localmente ou em um servidor remoto.
Figura 4O OpenFlow em ação
Quando um pacote chega a um equipamento com OpenFlow habilitado, os cabeçalhos do pacote são comparados às regras das entradas das tabelas de fluxos, os contadores são atualizados e as ações correspondentes são realizadas. Se não houver correspondência entre o pacote e alguma entrada da tabela de fluxos, o pacote é encaminhado, por completo, ao controlador. Alternativamente, apenas o cabeçalho é encaminhado ao controlador mantendo o pacote armazenado no buffer do hardware.
Normalmente, os pacotes que chegam ao controlador correspondem ao primeiro pacote de um novo fluxo ou, em função do tipo de pacote e da aplicação, o controlador pode optar por instalar uma regra no switch para que todos os pacotes de determinado fluxo sejam enviados para o controlador para serem tratados individualmente. Esse último caso corresponde, em geral, a pacotes de controle (ICMP, DNS, DHCP) ou de protocolos de roteamento (OSPF, BGP). Como exemplo de fluxo, têm-se todos os pacotes em uma faixa de endereços IP ( roteamento IP tradicional), uma conexão TCP em uma porta específica ou, ainda, todos os pacotes pertencentes a uma mesma VLAN. As ações associadas aos fluxos incluem:
a) encaminhar o fluxo de pacotes para determinada porta (ou portas);
b) modificar os campos do cabeçalho;
c) encapsular e transmitir o pacote para o controlador;
d) descartar os dados, como medida de segurança, com a implementação de firewalls, ou ainda para inibir ataques de negação de serviço;
e) encaminhar o pacote para o processamento normal do equipamento nas camadas 2 ou 3.
O último item garante que o tráfego experimental não interfira no processamento padrão do tráfego de produção. Conforme ilustrado na Figura 5, outra forma de garantir isso é definir um conjunto de VLANs para fins experimentais. Essa segmentação do tráfego permite ter equipamentos híbridos que processem tráfego legado conforme os protocolos e as funcionalidades embarcadas no equipamento e, ao mesmo tempo e de forma isolada, obter tráfego baseado na programabilidade do OpenFlow.
Figura 5Fatores críticos de sucesso
Existem quatro razões fundamentais que contribuem para a aceitação da tecnologia OpenFlow:
a) o OpenFlow pode ser incorporado em equipamentos de rede (roteadores, switches, pontos de acesso Wi-Fi) comerciais, atualmente, em operação, sem modificação do hardware e mediante uma atualização do firmware, garantindo o desempenho de tecnologias consolidadas no encaminhamento de pacotes IP/Ethernet, como, por exemplo, ASICs, FPGAs, etc.;
b) o protocolo OpenFlow separa o plano de controle do plano de dados, permitindo a utilização de controladores remotos baseados em servidores com sistemas operacionais e linguagens de programação comuns na indústria de TI. O software do controlador é responsável por definir o modo como os fluxos de pacotes são encaminhados e processados na rede. Isso permite que o controle sobre o plano de dados seja "terceirizado" a pesquisadores, sistemas de gerência, desenvolvedores, operadores de rede, plataformas de serviços e, até mesmo, às próprias aplicações finais, como, por exemplo, servidores de conteúdo ou serviços em nuvem. Dessa forma, o controle da rede deixa de estar embarcado nos equipamentos e limitado por implementações e padrões com mais de 15 anos de existência;
c) o OpenFlow não dependente da forma como o software controla a rede, e oferece um simples serviço de encaminhamento multicamada (L1-L4) orientado a fluxos definidos por qualquer combinação de mais de 20 cabeçalhos-padrão. Uma rede OpenFlow permite a definição de fatias de rede (slices ou flow-spaces), com garantia de isolamento entre os diferentes controladores que operam sobre a rede, permitindo que o tráfego operacional (conforme os protocolos tradicionais) e o tráfego experimental (conforme definido pelo usuário/operador da rede) operem em paralelo;
d) o OpenFlow é compatível com a Internet atual, cujo tráfego pode continuar em operação em uma ou mais fatias da rede OpenFlow. Todos os argumentos citados, anteriormente, apontam o OpenFlow como uma tecnologia inovadora que abre uma série de oportunidades de desenvolvimento tecnológico na área das redes de pacotes. Com a consolidação das tecnologias de equipamentos programáveis em software no padrão OpenFlow, ou tecnologias similares, o conceito de redes definidas por software envolve novos paradigmas de gerência integrada, inovação em protocolos e serviços baseados em recursos de redes virtualizados.
--------------------------------------------------------------------------------------------------------------------------------------------------
Esta postagem teve a maior parte do seu conteúdo retirada do Artigo "OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes" de Christian Esteve Rothenberg, Marcelo Ribeiro Nascimento, Marcos Rogério Salvador e Maurício Ferreira Magalhães.
Link para download:
Comentários
Postar um comentário