Artigo do tipo Teórico
OpenFlow: uma rede definida por software
Este artigo descreve um novo conceito utilizado para o controle da infraestrutura de dados: as redes definidas por software, também conhecidas como redes programáveis. Ao desvincular-se o desenvolvimento do hardware e do software dos equipamentos, há a possibilidade de conferir mais flexibilidade e agilidade na criação de novas arquiteturas e protocolos de comunicação. Este novo paradigma permite a utilização das inúmeras e conhecidas vantagens do software em uma área tradicionalmente dominada por hardwares proprietários.


Em que situação o tema é útil
O controle das redes de computadores por meio de softwares é ainda um tema incipiente e pouco difundido. Tornou-se mais conhecido após a publicação da tecnologia OpenFlow em 2008. Desde então, um número crescente de artigos e pesquisas foram desenvolvidos pelos fabricantes de hardware e pelos pesquisadores do meio acadêmico. Neste contexto, observou-se a importância da disseminação deste novo assunto entre os profissionais da área de tecnologia da informação, permitindo a contenda e o aprofundamento técnico do tema.

As atuais redes de computadores apresentam diversas demandas que precisam ser debatidas e tratadas, tais como: o crescimento das tabelas de roteamento, a complexidade de operação de muitos protocolos, o suporte à mobilidade dos usuários, a implementação de recursos de segurança, entre outras. A falta de ambientes que permitam a validação de novas arquiteturas e protocolos é uma das grandes dificuldades para a adoção de propostas que solucionam estas questões, pois não é possível reproduzir as mesmas características e volumes do tráfego real, além do comportamento de todos os equipamentos legados em operação.

Flexibilidade e agilidade, também são características que se fazem necessárias há algum tempo em equipamentos comuns, como switches e roteadores. Estes são formados por hardwares proprietários e engessados, os quais não possibilitam a personalização de seus recursos e funcionalidades.

As redes definidas por software (em inglês, Software Defined Networking – SDN) constituem um novo paradigma que propõe a desagregação entre o plano de dados (implementado em hardware especializado para suportar o desempenho requerido pelas redes atuais) e o plano de controle (executado em um ou mais servidores, os quais são responsáveis pela programação das ações realizadas pelo hardware).

Este artigo detalhará as necessidades que demandaram a concepção deste novo paradigma, além de apresentar os desafios atuais enfrentados pelas diferentes empresas do setor de telecomunicações para manutenção e operação de suas infraestruturas. A seguir, serão descritos os três principais componentes da arquitetura OpenFlow: as tabelas de fluxos, o canal seguro de comunicação entre o plano de dados e o de controle, e o protocolo OpenFlow. Também serão abordadas as diferentes informações disponíveis para caracterização de um fluxo. A importância das redes definidas por software será avaliada mediante a análise de um cenário relativamente simples, mas que impõe restrições que dificultam sua resolução por intermédio dos dispositivos e protocolos padrões (não proprietários) atualmente disponíveis. Por fim, serão apresentadas as mudanças e a evolução do OpenFlow especificadas em sua nova versão, além de sua adoção pelos fabricantes de hardware, provedores de serviços e operadoras de telecomunicações.

Por que as redes definidas por software são necessárias?

As redes se originaram a partir da necessidade da troca de dados entre as pessoas e os computadores, possibilitando a integração entre os sistemas instalados em diferentes localidades. Atualmente, as tecnologias que disponibilizam esta infraestrutura de conectividade estão inseridas em praticamente todas as atividades diárias da sociedade contemporânea. Estão presentes nas páginas web que viabilizam o comércio eletrônico, nos sistemas de internet banking ofertados pelas instituições financeiras, nas plataformas de e-mail, na educação à distância, nos aplicativos de navegação e roteirização baseados em GPS (Global Positioning System), e, mais recentemente, em dispositivos domésticos, como smartphones e televisores. Diversas iniciativas de inclusão digital são desenvolvidas por órgãos governamentais e privados com o objetivo de expandir ainda mais seu alcance para toda a população. Segundo o artigo Hobbes' Internet Timeline, o número de dispositivos conectados à Internet, rede mundial de computadores, brevemente será superior a um bilhão de equipamentos.

As pessoas, as corporações e os serviços públicos estão totalmente dependentes desta infraestrutura de comunicação. Você já imaginou como seria um dia sem acesso à Internet? Esta importância gera um problema para o desenvolvimento de novas tecnologias e protocolos de comunicação, pois as pesquisas não podem ser realizadas diretamente no ambiente de produção (aquele disponível e utilizado pelos usuários) devido ao risco de interrupção dos serviços essenciais. Além disso, a extensa adoção das tecnologias atuais e sua economia de escala inviabilizam a criação de novos recursos e funcionalidades que carecem de hardwares revolucionários. Em Redes definidas por software: uma abordagem sistêmica para o desenvolvimento de pesquisas em redes de computadores, os autores citam que diversos pesquisadores consideram que a arquitetura das redes de computadores atingiu um nível de amadurecimento tão alto que a tornou pouco flexível, ou seja, a Internet está calcificada (em inglês, ossified), uma analogia ao processo que substitui as cartilagens (mais elásticas) por ossos conforme o envelhecimento dos seres vivos.

O hardware atualmente empregado na infraestrutura das redes é basicamente formado por dispositivos proprietários e com alto custo de aquisição. Estes possuem sua arquitetura (plano de dados) concebida a partir de ASICs (Application-Specific Integrated Circuits) – circuitos integrados dedicados que asseguram o alto desempenho requerido por switches, roteadores, firewalls, balanceadores de carga, entre outros. Suportam ainda uma camada complementar de software (plano de controle) que programa os diferentes protocolos de redes. A comunicação entre o plano de controle e o de dados ocorre por meio de APIs (Application Programming Interfaces) proprietárias (Figura 1).

img

Figura 1. Hardware de um switch típico (proprietário).

Desta forma, a implementação de novos protocolos, a otimização nas lógicas de controle e o desenvolvimento de novos recursos, entre outras melhorias no plano de controle, estão restritas ao fabricante do hardware, resultando em um processo moroso e com altos custos. Este aspecto se antepõe ao crescimento exponencial do tráfego observado na Internet, bem como às tendências de virtualização dos servidores. As arquiteturas clássicas das redes de computadores sugerem restrições às aplicações e à inovação necessária aos serviços demandados pelos negócios e usuários da era da informação. Os desafios para o setor de telecomunicações são diversos:

· As operadoras de telefonia móvel precisam lidar com o congestionamento do espectro eletromagnético (propagador dos sinais de comunicação), a transição para as tecnologias IP (Internet Protocol) e o célere crescimento de seus usuários;

· O tráfego IP global atingiu um volume sem precedentes que necessita ser suportado pelos operadores de telecomunicações;

· O número de servidores e máquinas virtuais hospedados em Data Centers também está incrementando, exigindo infraestruturas internas com maior capacidade de comutação;

· Os pesquisadores da área de tecnologia da informação tratam, armazenam e transportam volumes imensos de dados.

Para atender a estes desafios, foi criado um novo paradigma: as redes definidas por software (também denominadas redes programáveis). Por meio desta arquitetura, a eficiência, a flexibilidade, a agilidade e a escalabilidade dos dispositivos de conectividade serão ampliados. As vantagens no uso dos softwares, já demonstradas nas diversas tecnologias existentes, foram estendidas para as redes de computadores. Segundo Marc Andreessen, co-fundador da Netscape, “Software is eating the world”, ou seja, as aplicações baseadas no modelo de operação da Internet serão amplamente utilizadas para transformar todos os setores da indústria.

Redes definidas por software

Estas constituem um novo padrão que propõe a desagregação do plano de controle e de dados habilitando a personalização em massa da infraestrutura para suportar serviços com diferentes características. Segundo o artigo OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes, os avanços na padronização de APIs independentes de fabricantes permitiram que a lógica de controle fosse movida para controladores externos, que podem ser disponibilizados por meio de servidores comuns e difundidos comercialmente. Esta separação possibilita que o comportamento da rede definida por software seja determinado por seus próprios usuários e fornecedores.

O plano de controle, instalado em servidores dedicados e com alta capacidade de processamento, é responsável pela programação remota dos dispositivos de conectividade por meio de uma API aberta (não proprietária). Assim, as principais vantagens do hardware e do software são extraídas, respectivamente: desempenho para o processamento e o encaminhamento dos pacotes, e flexibilidade para inserção, remoção e especialização de suas funcionalidades (Figura 2). Neste contexto surgiu o OpenFlow, tecnologia que será abordada na próxima seção.

img

abrir imagem em nova janela

Figura 2. Redes definidas por software.

OpenFlow

Publicado em 2008, o OpenFlow visa suportar novas propostas de protocolos e arquiteturas de rede sobre equipamentos comercialmente disponíveis. Descreve uma tecnologia para controlar as possíveis opções de encaminhamento de pacotes em switches e roteadores, entre outros dispositivos. A inteligência para a tomada destas decisões é responsabilidade de um elemento externo, chamado controlador OpenFlow, o qual pode ser instalado em servidores comuns (Figura 3).

img

abrir imagem em nova janela

Figura 3. Exemplo de dispositivos comerciais controlados pelo OpenFlow.

Em OpenFlow: Enabling Innovation in Campus Networks, os autores afirmam que o conceito básico deste paradigma baseia-se no fato de que a maioria dos switches e roteadores ethernet atuais empregam tabelas de fluxos para implementar as restrições de segurança (Access Control List – ACL), as traduções de endereços de rede (Network Address Translation – NAT), as regras de qualidade de serviço (Quality of Service – QoS) e para coletar estatísticas. Embora existam diferenças entre as dados armazenados (dependendo do fabricante), é possível identificar diversos campos comuns. Esta característica possibilita a especificação de um protocolo genérico para programar as tabelas de fluxos dos dispositivos de distintos fabricantes. Os fluxos são definidos pelos campos de cabeçalho do pacote processado, podendo incluir informações das camadas de enlace, rede e transporte conforme o modelo TCP/IP (Transmission Control Protocol/Internet Protocol – conjunto de protocolos que determinam o padrão de comunicação na Internet). A Figura 4 ilustra os campos de cabeçalho suportados pela versão inicial do OpenFlow (versão 1.0.0):

· Porta de entrada (ingress port): porta pela qual os pacotes foram recebidos;

· Identificação da VLAN (virtual local area network identification): número que possibilita a associação do pacote a sua rede local virtual;

· Endereço MAC de origem (source media access control address): também conhecido como endereço físico, indica o endereço do adaptador de rede do originador dos dados;

· Endereço MAC de destino (destination media access control address): identificador do adaptador de rede do destinatário;

· Tipo ethernet (ethernet type): especifica o tipo de pacote da camada de rede que é transportado;

· Endereço IP de origem (internet protocol source address): endereço lógico do originador dos dados;

· Endereço IP de destino (internet protocol destination address): define o endereço IP do receptor;

· Protocolo (protocol): identifica o protocolo da camada imediatamente superior (transporte);

· Porta TCP/UDP de origem (source transmission control protocol/user datagram protocol port): indica a porta TCP/UDP do transmissor do pacote;

· Porta TCP/UDP de destino (destination transmission control protocol/user datagram protocol port): especifica a porta TCP/UDP do destinatário.

img

abrir imagem em nova janela

Figura 4. Campos suportados pela versão inicial do OpenFlow (versão 1.0.0).

Em linhas gerais, a arquitetura OpenFlow é composta por três componentes (Figura 5):

· Tabela de fluxos: quando um pacote é recebido pelo dispositivo de rede, este é comparado com cada um dos fluxos registrados na tabela; caso encontre uma correspondência, considerar-se-á que o pacote pertence ao fluxo e aplicar-se-á as ações relacionadas. A seguir, serão atualizadas as estatísticas que controlam o número de pacotes, a quantidade de bytes e a duração daquele fluxo (Figura 6). Se um fluxo relacionado não for encontrado, o pacote será encaminhado para processamento no controlador OpenFlow;

· Canal seguro: assegura, por intermédio do protocolo SSL (Secure Socket Layer), que a troca de informações entre os equipamentos de rede e o comutador OpenFlow não tenha sua integridade comprometida. Para tanto, o SSL possibilita que todos os dados sejam criptografados;

· Protocolo OpenFlow (OpenFlow protocol – OPF): disponibilizado para estabelecer a comunicação entre os switches e roteadores, e o controlador. Por meio deste, são programadas as decisões tomadas nas tabelas de fluxos.

img

abrir imagem em nova janela

Figura 5. Componentes da arquitetura OpenFlow.

img

abrir imagem em nova janela

Figura 6. Estrutura da tabela de fluxos.

Dependendo do tipo de suporte ao OpenFlow, os dispositivos de rede podem ser agrupados em duas categorias:

· Switches OpenFlow dedicados: equipamentos que não implementam o processamento dos protocolos clássicos da camada de enlace e de rede;

· Switches com suporte OpenFlow: switches e roteadores ethernet comercialmente disponíveis que disponibilizam esta nova funcionalidade.

Os switches OpenFlow dedicados são comutadores que encaminham os pacotes para as portas somente com a especificação de um plano de controle remoto. Neste contexto, os fluxos podem ser definidos pelo endereço MAC de origem, pelos endereços IP de origem e destino, pela porta TCP de destino, entre outras combinações possíveis para os campos de cabeçalho suportados (Figura 7).

img

abrir imagem em nova janela

Figura 7. Exemplos de registros de fluxos.

Cada registro na tabela de fluxos possui uma ação associada. Para os switches OpenFlow dedicados, foram determinadas três opções:

1. Encaminhar os dados do fluxo para uma ou mais portas, permitindo que sejam propagados pela rede;

2. Encapsular e encaminhar o pacote para o controlador por intermédio do canal seguro (SSL). Geralmente, esta ação é tomada para o primeiro pacote dos fluxos desconhecidos. Desta maneira, após o processamento pelo controlador OpenFlow, uma ação será definida, e os dados registrados em sua tabela. Em situações específicas, todos os pacotes de certos fluxos podem ser tratados individualmente pelo controlador: por exemplo, aqueles gerados por protocolos de roteamento, como OSPF (Open Shortest Path First) e BGP (Border Gateway Protocol), ou ainda, relacionados às funções de controle, como ICMP (Internet Control Message Protocol) e DHCP (Dynamic Host Configuration Protocol), entre outros;

3. Descartar os pacotes do fluxo. Restrições de segurança, mitigação dos ataques de negação de serviços ou redução no volume de tráfego broadcast são possíveis razões para esta decisão.

Com a popularização do OpenFlow, os switches, os roteadores e os pontos de acesso wireless (access points) comercialmente disponíveis passaram a disponibilizar os componentes desta nova arquitetura. Estes equipamentos, denominados switches com suporte OpenFlow, implementam uma quarta ação aos fluxos:

4. Encaminhar os pacotes para o processamento padrão das camadas de rede e enlace.

Ao criar esta camada de abstração da infraestrutura física, o controlador OpenFlow possibilita o desenvolvimento de serviços e aplicações para gerenciar a tabela de fluxos dos dispositivos de rede. Segundo os autores do artigo OpenFlow e redes definidas por software: um novo paradigma de controle e inovação em redes de pacotes, este princípio de operação é similar ao que já existe em outros sistemas de software que suportam recursos reutilizáveis e abstração do hardware. A separação do plano de controle desvincula sua evolução do plano de dados, tornando possíveis frentes paralelas e independentes de melhoria.

Aplicação do OpenFlow

Conforme exposto nas seções anteriores, a infraestrutura de redes atual é pouco flexível, pois qualquer projeto deve seguir as especificações suportadas pelos fabricantes. Os recursos disponíveis são engessados pelos protocolos padrões existentes (internet standards), tais como:

· Camada de enlace:

o Spanning tree protocol;

o Multiple spanning tree protocol;

o Rapid spanning tree protocol;

o Virtual local area network;

o Queue-in-queue encapsulation;

o Entre outros.

· Camada de redes:

o Virtual router redundancy protocol;

o Virtual private LAN service;

o Open Shortest Path First;

o Border Gateway Protocol;

o Etc.

Portanto, os engenheiros de redes precisam selecionar entre as peças existentes, aquelas que se encaixam para propor as soluções para seus problemas. Por exemplo, suponha o cenário da Figura 8. Neste, todas as estações foram configuradas com endereçamento IP na sub-rede 1.1.1.0/24. Deseja-se separá-las em dois grupos: o primeiro, composto pelos computadores 1, 4 e 5 (azul); e o segundo, por 2, 3 e 4 (vermelho). Note que a estação 4 é a única que pode se comunicar com ambos os grupos. A infraestrutura foi configurada com os dispositivos A, B, C e D. Neste simples exemplo, qual seria a topologia de rede que suportaria estes requisitos, considerando as tecnologias atualmente disponíveis?

img

abrir imagem em nova janela

Figura 8. Exemplo de topologia com dois grupos de usuários.

Uma proposta inicial (Figura 9) poderia sugerir a utilização de hubs (repetidores) nas posições A, B, C e D. Entretanto, nesta topologia seria necessária a utilização do protocolo spanning tree protocol (ou de suas variantes) para remover logicamente os caminhos redundantes existentes (observe que existem duas possibilidades distintas entre as estações 1 e 2, e as estações 3, 4 e 5: a primeira, passando por A, B e D; e a outra, por A, C e D). Este protocolo evita a ocorrência de loops na comunicação de rede, desabilitando logicamente as conexões físicas duplicadas (tornando-as disponíveis somente em situações de contingenciamento). Todavia, o spanning tree protocol não é suportado em hubs, somente switches disponibilizam este recurso. Este cenário inicial também não atenderia ao requisito de separação em dois grupos, visto que todas as estações poderiam comunicar-se entre si.

img

abrir imagem em nova janela

Figura 9. Proposta inicial de solução com o uso de hubs.

A solução descrita na Figura 10 admite a hipótese que A, B, C e D são switches. Logo, poderiam ser criadas duas VLANs para separação das estações. O spanning tree protocol trataria a questão dos caminhos redundantes. Entretanto, como o computador 4 poderia participar de ambos os grupos? Segundo os requisitos apresentados, esta estação possui somente um adaptador de rede e um único endereço IP. A configuração de subinterfaces de redes com suporte a 802.1Q (recurso conhecido como vlan tagging, que permite a uma placa de rede ser configurada em diversas vlans) também não seria viável, visto que não é recomendada a configuração do mesmo endereço IP em ambas as subinterfaces.

img

abrir imagem em nova janela

Figura 10. Proposta de topologia com switches.

A partir destes exemplos, observa-se que determinadas necessidades, por mais simples que sejam, resultam em dificuldades para os profissionais da área de infraestrutura. Neste contexto, nota-se a importância das redes definidas por software, mais especificamente, do OpenFlow. Por meio deste, os planos de dados dos switches A, B, C e D poderiam ser configurados para apresentar o comportamento descrito inicialmente, conforme as tabelas de fluxos da Figura 11.

img

abrir imagem em nova janela

Figura 11. Tabelas de fluxos configuradas nos switches A, B, C e D.

Evolução do OpenFlow

Segundo o artigo OpenFlow Switch Specification Version 1.1.0, a versão 1.1.0 deste protocolo foi apresentada em Dezembro de 2010. Nesta, o switch OpenFlow suporta múltiplas tabelas de fluxos organizadas e numeradas sequencialmente a partir do número 0 (Figura 12). O processo de busca inicia-se na tabela zero. Outras tabelas podem ser consultadas dependendo das ações correspondentes aos fluxos.

img

abrir imagem em nova janela

Figura 12. Múltiplas tabelas de fluxos.

Portanto, quando uma associação é encontrada, o pacote pode ser explicitamente direcionado para a tabela seguinte utilizando a instrução go-to (encaminha para). Este é um procedimento que pode ser sucessivamente repetido. A configuração aplicada ao controlador OpenFlow determina diferentes comportamentos quando não se encontra a ação correspondente para um pacote nos registros das tabelas de fluxos:

1. Encaminhamento para processamento no controlador;

2. Envio para a próxima tabela de fluxos (se houver);

3. Descarte dos dados.

Nesta nova versão também foram adicionados novos campos para caracterização dos fluxos, entre eles (Figura 13):

· Metadado (metadata): empregado para a troca de informações entre as tabelas de fluxos no processamento sequencial;

· Prioridade da vlan (VLAN priority): bits PCP (priority code point) que indicam a prioridade do quadro (frame) ethernet. Geralmente utilizados para conceber classes de tráfego para voz, vídeo, dados, entre outras aplicações;

· Etiqueta MPLS (multi-protocol label switching tag): identificador (tag) configurado nas redes MPLS (infraestruturas baseadas em pacotes rotulados, na qual cada etiqueta representa um índice na tabela de roteamento do próximo roteador);

· Classe de serviço MPLS (MPLS traffic class): permite a criação de níveis de prioridade para a definição de políticas de qualidade de serviço;

· Tipo de serviço IP (IP type of service): diferencia os pacotes transportados, classificando-os para que possam ter prioridade na transmissão.

img

abrir imagem em nova janela

Figura 13. Campos suportados pela versão 1.1.0 do OpenFlow.

Cada registro na tabela de fluxos está associado a um conjunto de instruções. Estas podem alterar campos dos cabeçalhos nos pacotes, realizar ações específicas e/ou continuar o processamento sequencial nas tabelas. Entre as instruções suportadas, destacam-se:

· Aplica as ações (apply-actions): confirma a execução das ações. Pode ser utilizada para modificar os pacotes entre duas tabelas ou para programar múltiplas ações do mesmo tipo;

· Remove as ações (clear-actions): remove imediatamente todas as ações;

· Grava as ações (write-actions): grava as ações inseridas, alteradas ou removidas no conjunto existente;

· Grava os metadados (write-metadata): grava os metadados inseridos, alterados ou removidos no conjunto atual;

· Encaminha para (go-to): indica a próxima tabela no processamento sequencial, observando que sua identificação (número) deve ser maior que a anterior. Esta instrução não é válida para a última tabela de fluxos.

Por fim, a versão 1.1.0 suporta mais ações que a especificação anterior, tais como: mudanças de campos no cabeçalho, mapeamento dos pacotes para certas classes de prioridades, cópia e decremento do TTL (time-to-live), entre outras.

Conclusões

A infraestrutura de redes de computadores fundamentada nos protocolos clássicos das camadas de enlace e de redes está presente nos serviços disponibilizados por empresas públicas e privadas aos seus milhões de usuários. O célere crescimento da Internet, caracterizado pelo uso intensivo da navegação na web, do correio eletrônico, das redes sociais e dos programas de mensagens instantâneas, torna a rede mundial de computadores um serviço essencial às pessoas e corporações. Estas aplicações são suportadas, em sua maioria, por switches e roteadores proprietários e altamente especializados. As necessidades de desenvolvimento de novos protocolos e recursos nestes equipamentos devem ser homologadas e implementadas por seus fabricantes, conforme sua disponibilidade, interesses e procedimentos internos. Destarte, o processo de evolução geralmente é dispendioso e moroso, antepondo-se as necessidades da era da informação, marcada pela virtualização dos servidores, pela computação nas nuvens e pelo crescimento exponencial do tráfego na Internet.

Neste cenário foram concebidas as redes definidas por software, as quais objetivam desagregar os planos de dados (hardware) e controle (software) a fim de usufruir suas melhores características, respectivamente: desempenho e flexibilidade/agilidade. Atualmente, o OpenFlow é uma das tecnologias mais disseminadas que permite a adoção deste novo paradigma de controle e inovação. Seu potencial disruptivo já foi observado pelos principais fornecedores de hardware. Equipamentos de empresas como Cisco Systems, Juniper Networks, Brocade Communications, Extreme Networks, Arista, entre outras, já suportam esta tecnologia. Provedores de serviços e operadoras, como Amazon, Facebook, Google, Deutsche Telekom e Docomo, também iniciaram seus testes de homologação e possuem infraestruturas controladas por arquiteturas baseadas em OpenFlow.

Assim, observa-se uma tendência na qual as redes programáveis serão o alicerce a uma era de inovação nos dispositivos de redes, envolvendo pesquisadores, profissionais dos setores de telecomunicações e fabricantes. Provavelmente esta evolução ocorrerá com uma velocidade nunca antes observada, possibilitando o desenvolvimento de novas arquiteturas, protocolos e serviços personalizados para as demandas atuais da era da informação.

Links

Artigo “Hobbes' Internet Timeline 10.2”, escrito por Robert H'obbes' Zakon.
http://www.zakon.org/robert/internet/timeline

Artigo “Redes definidas por software: uma abordagem sistêmica para o desenvolvimento de pesquisas em redes de computadores”, escrito por Dorgival Guedes, Luiz Filipe Menezes Vieira, Marcos Menezes Vieira, Henrique Rodrigues e Rogério Vinhal Nunes.
http://sbrc2012.dcc.ufmg.br/app/pdfs/p-04/mc4.pdf