Aplicação em SDN que gerencia o controle de fluxo para permitir uma rede inteligente. São baseados em protocolos, como o OpenFlow, que permitem aos servidores comunicar os comutadores para onde enviar os pacotes.

O controlador funciona como uma espécie de sistema operacional para a rede. Ao retirar o plano de controle do hardware da rede e executando como software, o controlador facilita o gerenciamento automatizado da rede, facilitando a integração e administração de aplicativos.

A seguir, alguns exemplos de controladores:

Como o nome sugere, é um comutador virtual com código aberto que implementa o protocolo OpenFLow. Simulando comutadores em ambientes virtuais, ele permite que máquinas virtuais se comuniquem entre si em um mesmo host ou até mesmo realizar a comunicação com a rede física.

O OVS é executado como se fosse uma distribuição Linux, porém pode ser utilizado em nível de usuário ao custo de perder desempenho e acesso à alguns recursos. Ele também pode ser executado na maioria das plataformas virtuais, como por exemplo VirtualBox, facilitando assim a realização de testes.

Atualmente o OVS fornece ao usuário o controle de diversos recursos, entre eles:

O FlowVisor não passa de um controlador OpenFlow que tem como principal característica atuar como um middleware entre os comutadores e os outros controladores OpenFlow. Todas as mensagens que são trocadas entre comutadores 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

Projeto de código aberto que tem como objetivo fornecer serviços virtualizados de roteamento IP utilizando o protocolo OpenFlow.

Ele facilita a criação, remoção e aperfeiçoamento de protocolos das redes IP realizando a separação do plano de controle do plano de encaminhamento. Podemos definir o RouteFlow em três partes:

RouteFlow Protocol - Contém os comandos básicos do RouteFlow para realizar as configurações necessárias nas máquinas virtuais.

RouteFlow Controller - É uma aplicação baseada no controlador NOX. Ele é responsável por gerenciar o recebimento dos pacotes, o estado dos computadores(conectados/desconectados) e as conexões entre os comutadores e as máquinas virtuais

RouteFlow Slaves - São aplicações que são executadas nas máquinas virtuais da rede. São responsáveis pela comunicação da máquina com o controlador e consequentemente com o resto da rede.

O comutador OpenFlow

Como a maioria dos equipamentos Ethernet modernos contêm tabelas de fluxo, o Openflow usa isso para implementar serviços, como firewalls, NAT, QoS, além de coletar estatísticas. Ao mesmo tempo em que as tabelas de fluxo variam de vendedor para vendedor, há funções comuns a vários equipamentos distintos, que o Openflow busca utilizar. Este é o cerne do Openflow: fornecer um protocolo aberto para programar as tabelas de fluxo em diferentes equipamentos. Isto atende os objetivos:

• O administrador de rede pode particionar o tráfego, separando o experimental do de produção
• Permite a pesquisa ao possibilitar que pesquisadores controlem seus próprios fluxos, ao escolher a rota que seus pacotes devem seguir e o processamento que devem receber
• De uma forma pouco custosa, permite que pesquisadores testem novos protocolos (até substitutos ao IP), modelos de segurança etc.
• Não se contrapõe aos equipamentos fechados já existentes, como veremos a seguir

O comutador consiste de, no mínimo, três partes:

• A tabela de fluxos, que para cada fluxo de entrada (ou seja, pacotes cujos cabeçalhos satisfazem determinadas características) informa ao comutador como o pacote deve ser processado, através de uma série de ações que devem ser executadas
• O chamado Canal Seguro, que conecta o comutador ao controlador (remoto), e que possibilita a troca de pacotes e comandos entre os dois
• O Protocolo Openflow, que padroniza a comunicação entre o controlador e o comutador. É a interface com a qual as tabelas de fluxos podem ser definidas externamente

Esquema simples do comutador:

Cada entrada da tabela associa os pacotes cujos cabeçalhos correspondem a determinadas regras a uma das seguintes ações básicas:

• encaminhar os pacotes a determinada(s) porta(s), que permite o roteamento através da rede
• encapsular e encaminhar os pacotes para o controlador, através do Canal Seguro. Em geral, o primeiro pacote de um determinado fluxo é encaminhado ao controlador para que este decida se deve ser adicionada à tabela uma entrada correspondente ao fluxo
• descartar os pacotes do fluxo (ex. para segurança, bloqueando pacotes de determinadas origens)
• enviar o pacote para a próxima tabela de fluxo
• encaminhar os pacotes do fluxo através da pipeline normal de processamento nas Camadas 2 e 3 do comutador (possibilita a utilização de equipamentos proprietários e fechados)

Caminho do pacote:

As tabelas de fluxo possuem 3 campos:

• cabeçalho dos pacotes que definem o fluxo
• instruções associadas ao fluxo, que definem como os pacotes serão processados
• estatísticas: número de pacotes e bytes em determinado fluxo e o tempo desde o último pacote naquele fluxo (que facilita a remoção de fluxos inativos)

Campos do cabeçalhos usado nas regras:

Exemplo de tabela de fluxo:

Protocolo OpenFlow

Há 3 tipos de mensagem:

• Controlador para comutador

São mensagens iniciadas pelo controlador e podem exigir ou não resposta. Como exemplos, o controlador pode:

• requisitar as funcionalidades que o comutador possui
• perguntar ou determinar as configurações do comutador
• modificar o estado das tabelas de fluxo, adicionando, excluindo, ou modificando as entradas
• ler as estatísticas do comutador
• Assíncrona

São mensagens enviadas pelo comutador sem solicitação por parte do controlador. Como exemplos, o comutador pode avisar o controlador:

• caso um pacote não tenha satisfeito nenhuma regra da primeira tabela de fluxo. Dependendo da configuração do comutador, ao invés de enviar o aviso, pode descartar o pacote ou checar a próxima tabela.
• quando uma entrada da tabela de fluxo for excluída. Isto ocorre, por exemplo, devido às datas de expiração (dependendo ou não de inatividade)
• caso haja algum problema, através da mensagem de erro
• Simétrica

São mensagens enviadas em ambas as direções, sem solicitação prévia. Podem ser mensagens:

• 'hello' (para iniciação de conexão)
• 'echo' (servem para medir a latência, por exemplo)