A arquitetura das redes definidas por software pode ser dividida em cinco partes principais: os planos de gerenciamento, controle e dados e as interfaces para o norte (Northbound Interface) e para o sul (Southbound Interface), que serão descritos a seguir.
Plano de Gerenciamento
O plano de gerenciamento é a interface entre a SDN e o administrador da rede. Por meio dele, é possível programar os equipamentos da rede para desempenhar várias funções, além de obter informações sobre o estado da rede e notificações sobre eventos que ocorreram. Essas funções são realizadas de forma facilitada devido às APIs (Application Programming Interfaces) que realizam a comunicação entre ele e o controlador, além das linguagens de programação usadas nas aplicações desse plano, que fornecem várias abstrações, facilitando a programação das aplicações e o reuso de código.
As principais aplicações de rede em uma SDN exercem as funções mais comuns em uma rede de computadores: roteamento, balanceamento de carga e aplicação de políticas de segurança. Além disso, algumas funções mais novas são realizadas, como economia de energia, aplicação de Qualidade de Serviço (Quality of Service – QoS) fim-a-fim, virtualização de redes, gerenciamento de mobilidade em redes sem-fio, engenharia de tráfego, e muitas outras. A quantidade e variedade de aplicações de rede que podem ser desenvolvidas com rapidez e maior facilidade por meio das APIs e linguagens de programação é um dos argumentos mais fortes para a adoção de uma SDN.
Northbound Interface
A Northbound Interface (interface para o norte, em português) é uma peça chave da arquitetura da SDN. Ela é uma API que faz a comunicação entre o plano de gerenciamento e o plano de controle, efetivamente permitindo que aplicações utilizadas por administradores de rede efetuem o controle e o monitoramento das funções da rede sem ter que ajustar os detalhes mais finos da comunicação. Isso é possível também devido à Southbound Interface, descrita mais adiante.
O ideal para esse tipo de interface é que um padrão seja estabelecido, de modo que seja gerada uma abstração que independa da linguagem de programação e do controlador. No entanto, isso ainda não foi definido. Cada controlador especifica sua própria API.
As funções principais de uma interface para o Norte são traduzir os requisitos das aplicações de gerenciamento em instruções de baixo nível para os dispositivos da rede e transmitir estatísticas sobre a rede, que foram geradas nos dispositivos da rede e processadas pelo controlador.
Plano de Controle
Esse plano concentra a “inteligência” da rede definida por software. Ela é composta pelo sistema operacional da rede (Network Operating System - NOS), que oferece um controle centralizado logicamente (o que não necessariamente implica na existência de um único controlador físico). Como qualquer outro sistema operacional, ele fornece abstrações, serviços essenciais e APIs para desenvolvedores. Isso significa que um desenvolvedor não precisa mais saber de todos os detalhes de uma transmissão de pacotes para definir uma política de rede, facilitando o seu desenvolvimento e diminuindo a chance de erros. Geralmente, ele pode ser instalado em um computador de porte médio.
As funções principais de um NOS são: análise do estado da rede, fornecimento de informações sobre a topologia, descoberta de dispositivos conectados à rede, distribuição de configurações da rede, gerenciamento de dispositivos, encaminhamento de dados pelo caminho mais curto, mecanismos de segurança, além de recebimento, processamento e encaminhamento de eventos. Recursos de segurança são de primordial importância, pois eles provêm isolamento e aplicação de regras entre serviços e aplicações.
Um NOS deve fornecer uma interface comum para as camadas superiores, enquanto permite que uma plataforma de controle use diferentes Southbound APIs e plug-ins de protocolos, assim permitindo gerenciar diferentes dispositivos da rede, além de oferecer compatibilidade entre diferentes versões.
Existem controladores centralizados e distribuídos. Os centralizados possuem uma clara desvantagem: o único controlador da rede é um ponto único de falha. Além disso, um único controlador pode não ser o suficiente para gerenciar uma rede com muitos elementos no plano de dados. No entanto, explorando o paralelismo em computadores de alto desempenho, é possível usar um NOS centralizado para processar milhões de fluxos por segundo, podendo atender a redes de data centers.
Já um controlador distribuído pode ser escalado para atender aos requisitos de qualquer ambiente. Ele pode ser um conjunto de nós concentrados em uma localidade ou vários elementos de processamento distantes um do outro. A vantagem de um controlador distribuído é a maior resiliência para falhas de físicas e lógicas. No entanto, um obstáculo é manter o estado da rede sempre atualizado para todos os componentes do controlador.
Para a comunicação entre os nós do controlador, são usadas APIs especiais, chamadas de Westbound API e Eastbound API (em português, interface para o oeste e interface para o leste, respectivamente). Cada controlador implementa suas próprias APIs desse tipo. Algumas de suas funções são transmissão de dados entre os nós do controlador, algoritmos para a manutenção da consistência dos dados e recursos de monitoramento e notificação (por exemplo, verificar se um dos nós está ligado e notificação de que um nó assumiu o lugar de outro no controle de um conjunto de dispositivos de rede).
Southbound Interface
A Southbound Interface (ou interface para o sul, em português) é a ponte entre os elementos de controle e encaminhamento de dados. Esse o elemento vital para a separação entre os planos de controle e dados. Essa interface também é uma API. É por meio dela que os controladores da SDN podem comunicar os requisitos das aplicações para a rede, reprogramando os equipamentos para que eles desempenhem inúmeras funções, como controle de fluxo, firewall, sistemas de detecção de intrusos (IDS), além de roteamento e comutação. Essa reprogramação é feita adicionando ou removendo regras das tabelas de fluxo, que serão descritas com detalhes na descrição sobre o plano de dados.
Além disso, essa API é usada para os equipamentos de rede se comunicarem com o controlador. Isso ocorre em três casos:
-
Envio de avisos de eventos caso ocorra uma mudança de porta ou enlace.
-
Envio de estatísticas de fluxo geradas com o tempo e enviadas para o controlador, de forma a fornecer informações mais detalhadas sobre as características da rede para administradores da rede.
-
Envio de pacotes para o controlador em dois casos: se os equipamentos do plano de dados não souberem o que fazer com um pacote, ou seja, quando não há uma regra definida para pacotes com alguma característica; ou quando alguma das regras instaladas no equipamento têm como comando “enviar para o controlador”.
Todos esses tipos de comunicação estão definidos na Southbound Interface mais utilizada, o OpenFlow. No entanto, há outras APIs, como OVSDB, ForCES e OpFlex, que adicionam novas funções. Por exemplo, a interface OVSDB permite aos elementos de controle a criação de várias instâncias de comutadores virtuais, configurar políticas de Qualidade de Serviço nas interfaces, configurar túneis e gerenciar filas. Por isso, ela é uma interface complementar ao OpenFlow para o uso com Open vSwitch.
Plano de Dados
O papel do plano de dados é encaminhar os dados na rede. Ele é composto de dispositivos de encaminhamento. Esses dispositivos são elementos de hardware ou software especializados em encaminhar pacotes. Porém, diferentemente de roteadores, comutadores ou middleboxes convencionais, eles não carregam implementações de protocolos e programas complexos. A “inteligência” está concentrada no plano de controle. Em um dispositivo configurado para OpenFlow, por exemplo, apenas estão instaladas tabelas de fluxos, que decidem as ações que serão tomadas com cada pacote. Elas são compostas de regras de compatibilidade de fluxos, isto é, regras de comparação que verificam valores de campos do cabeçalho do pacote, como o destino, protocolo e número de porta com algum valor esperado, e ações a serem tomadas com o pacote caso a regra valha. Ações que podem ser realizadas são:
-
Encaminhar o pacote para uma porta de saída
-
Encapsular e encaminhar o pacote para o controlador
-
Descartá-lo
-
Enviá-lo para o pipeline de processamento
-
Enviá-lo para a próxima tabela de fluxos ou para alguma tabela especial
Caso nenhuma regra seja satisfeita, o pacote pode ser descartado, mas o mais comum é que seja criada uma regra padrão (default) que encaminhe qualquer pacote que não satisfaça nenhuma das outras regras para o controlador.
A prioridade entre as regras segue a ordem das linhas de uma tabela e, posteriormente, a ordem das tabelas em uma sequência de processamento.
A imagem abaixo descreve, de forma resumida, a arquitetura de uma SDN.
