OpenFlow

Arquitetura

Elementos da topologia

A infraestrutura do OpenFlow é composta por um plano de dados com comutadores dentro das especificações do OpenFlow, por um plano de controle com um ou mais controladores e por um canal seguro que viabiliza a comunicação entre os controladores e os comutadores.

Na arquitetura do OpenFlow pode-se ter os comutadores OpenFlow projetados dentro das especificações do protocolo ou componentes físicos que simulem o protocolo. Em ambas as possibilidades, não são eles que tomam as decisões relacionadas aos dados. Eles apenas recebem o tráfego de dados e executam as ações referentes aos metadados dos pacotes que chegam.

Na infraestrutura da Internet há vários tipos de comutadores dos mais variados fabricantes. Um comutador OpenFlow é aquele que atende as especificações técnicas. Desta forma, encontram-se diferentes modelos dentro das especificações estabelecidas e não há dependência de um só fabricante. Então, um padrão é implementado na interface de comunicação entre o controlador e a infraestrutura, de forma que a garantir que essa interface administre diferentes modelos de comutadores.

Figura 1 - Simplificação da topologia do OpenFlow. Fonte: Migração de redes tradicionais para SDN

As aplicações de rede podem controlar o comportamento da rede por meio da abstração da infraestrutura que o controlador apresenta. A principal vantagem do ponto de vista de quem desenvolve as aplicações é que não é necessário conhecer todos os componentes da rede, bastando apenas definir como a rede se comportará num conjunto de possibilidades.

Para além da separação do gerenciamento do Plano de Controle e do Plano de Dados, há componentes importantes para a composição do OpenFlow. São esses o controlador, as tabelas de fluxo e o canal seguro.

Controlador

O controlador é o componente responsável pelas regras e ações que gerenciam o encaminhamento de pacotes. Ele se comunica com o plano de dados e com as aplicações permitindo a comunicação entre esses, garantindo flexibilidade em diversificadas aplicações. O controlador abstrai o que seria a configuração, a priori, dos comutadores.

As seguintes mensagens podem ser trocadas entre o comutador e o controlador:

Controlador para comutador: Para saber as funções disponíveis, para configurar ou obter as configurações e para obter informações.

Comunicação assíncrona: é feita do comutador a qualquer momento para o controlador para notificar erros ou mudanças de estados e para sinalizar a chegada de pacotes.

Comunicação síncrona: tanto o controlador quanto o comutador podem solicitar sem aviso prévio e mensagens como “echo” e “hello” podem ser trocas, muitas vezes para verificar se o canal seguro está disponível.

Figura 2 - Especificação do comutador OpenFlow. Fonte: https://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2010_2/rodrigo/funcionamento.html

Uma vez que o pacote chega em um comutador, o cabeçalho desse é comparado com os cabeçalhos das entradas das tabelas de fluxo. A partir disso, as principais ações podem ser tomadas:

Encaminhamento do pacote para uma determinada porta;

Descarte do pacote;

Redirecionamento do pacote para o controlador;

Modificação dos campos de cabeçalho do pacote.

Tabelas de Fluxo

Um fluxo representa um tipo de pacote que pode chegar nas entradas dos comutadores. As regras das tabelas de fluxo são definidas de acordo com os de pacotes que serão recebidos. A configuração é baseada nos metadados e nos campos de cabeçalho que estarão juntos ao pacote.

Figura 3 - Generalização das tabelas de fluxo. Fonte: Software Defined Networks

É na entrada da tabela que está definido o pacote que será tratado e nele há campos que são usados na descrição de um fluxo. Esses campos guardam informações como a porta de entrada do fluxo e IP de origem. Dados associados a quantidade de dados, pacotes transmitidos e o tempo de transmissão são determinados pelos contadores como forma de obter dados estatísticos. Ainda, a depender do fluxo, diferentes ações podem ser tomadas e quem as define é o controlador. Essas ações são definidas nos cabeçalhos das Tabelas de Fluxo. A figura 3 representa genericamente a composição das entradas de uma tabela.

Figura 4 - ECabeçalho das tabelas de fluxo. Fonte: https://blog.pantuza.com/artigos/o-protocolo-openflow

A figura 4 representa o cabeçalho associado a um pacote. O cabeçalho é varrido e enviado para o controlador, esse faz o processamento e retorna com as regras das tabelas. O processamento consiste numa comparação do cabeçalho do pacote com o cabeçalho da tabela, se forem iguais, o pacote pertence ao fluxo comparado e as regras são atribuídas a ele.

As especificações permitem dois modos para definir as regras das tabelas de fluxo:

Reativo: os fluxos são configurados quando um determinado pacote chega e possui uma marcação em seu cabeçalho para determinar esses.

Proativo: os fluxos são previamente configurados nos comutadores;

Canal Seguro

É por meio do Canal Seguro que o controlador se comunica com os comutadores e a conexão é do tipo TCP (Transmission Control Protocol). É possível criptografar as mensagens entre os comutadores e o controlador por meio do TLS (Transport Layer Security) ou SSL (Secure Socket Layer).

É por meio do Canal Seguro que o Controlador distribui as regras de encaminhamento. A segurança na comunicação entre o controlador e o comutador pode ser primordial a depender da aplicação.

Controlador OpenFlow: Out-of-Band e in-Band

Há duas maneiras do Controlador OpenFlow se comunicar com os comutadores. No primeiro, Out-of-Band, o controlador tem um caminho para se comunicar com os comutadores OpenFlow que não é o caminho usado pelo OpenFlow para a comunicação com os comutadores. No segundo, in-Band, o caminho usado na comunicação com os comutadores é igualmente usado pelo controlador para se comunicar com esses.

Figura 2 - Comunicação Out-of-Band e in-Band. Fonte: https://www.researchgate.net/figure/In-band-vs-Out-of-band-The-dashed-lines-represent-OpenFlow-controlled-links_fig1_262274156

Para viabilizar controle OpenFlow Out-of-Band é necessário estabelecer VLANs ou interfaces físicas que não estão submetidas ao protocolo OpenFlow.

Protocolo

Primeiramente, para entender o protocolo OpenFlow, é necessário entender o que é definido como um fluxo, pois toda a decisão de encaminhamento do OpenFlow se dá por parte das tabelas com decisões definidas pelos fluxos. Um fluxo é constituído pelos cabeçalhos do pacote a ser processado pelo dispositivo encaminhador, assim o fluxo pode ser caracterizado pelos campos das camadas de enlace, de rede ou de transporte. Podemos dar como exemplos simples de fluxo como todos os pacotes em uma faixa de endereços IP ou uma conexão TCP em uma porta específica.

No momento que um pacote chega a um elemento da rede com OpenFlow, seus cabeçalhos são analisados e comparados as entradas da tabela de fluxos. Se houver uma correspondência, os contadores são atualizados e as ações correspondentes são realizadas. Se houver correspondência à mais de uma entrada da tabela, é escolhida a entrada com maior prioridade, por exemplo a que apresenta a entrada mais específica. Caso não exista correspondência com uma entrada da tabela, o pacote é enviado ao controlador que instala uma nova regra nos elementos de encaminhamento com base nesse pacote, que normalmente indica o começo de um novo fluxo. Entre exemplos de ações a serem tomadas, temos a modificação de cabeçalho, descartamento de pacotes, encaminhamento dos pacotes ou envio dos pacotes para o controlador (normalmente para pacotes de controle).

A seguir, uma breve descrição das 4 primeiras versões:

OpenFlow 1.0.0: A versão mais comumente implementada. Há uma ordem na correspondência de campos, começando pelos cabeçalhos de enlace e indo até os de transporte. Várias ações podem ser tomadas para um fluxo e estatísticas do fluxo são tomadas;

OpenFlow 1.1.0: Similar à versão anterior mas com mudanças significativas. Não há mais só uma tabela de fluxos, mas várias. Uma entradas numa tabela de fluxo pode ter, além de ações, uma indicação para outra tabela de fluxos. Assim, um pacote pode sofrer ações de diferentes tabelas de fluxo encadeadas. Além disso, uma tabela de fluxos pode apontar para algo novo chamado de tabela de grupos. A tabela de grupos apresenta operações comuns a diversos fluxos;

OpenFlow 1.2.0: As principais mudanças dessa versão são a compatibilidade com o IPv6 e a possibilidade de conectar um comutador a diversos controladores;

OpenFlow 1.3.0: Novas ferramentas de monitoramento e gerenciamento foram adicionadas. Por exemplo, foram adicionadas as “meter tables” para controlar a taxa dos fluxos. Além disso agora são possíveis conexões auxiliares entre os controladores e os comutadores.