3.2 Arquitetura SDN
3.2.6 Plano de Controle
O plano de controle em SDN atua como uma camada intermediária entre as aplicações e o plano de dados e, do ponto de vista prático, pode ser comparado a um sistema operacional [56]. Tradicionalmente, um sistema operacional provê abstração, ser-
Capítulo 3. Software-defined Networking (SDN) 49
viços essenciais e uma API comum para desenvolvedores. A arquitetura SDN utiliza esses recursos para facilitar o gerenciamento da rede e descomplicar a resolução de problemas por meio do controle logicamente centralizado fornecido por um ou mais controladores. As funções essenciais de rede como manutenção das informações da topologia, descoberta de novos dispositivos conectados e configuração dos dispositivos de encaminhamento são exemplos de serviços desempenhados pelo plano de controle. Além disso, a API provida pelos controladores permite aos administradores não se preocuparem com detalhes de baixo nível de switches e roteadores quando forem estabelecer ou modificar políticas.
O controlador corresponde a uma entidade de software que possui controle exclusivo sobre um conjunto de recursos do plano de dados [62]. É também considerado um elemento crítico na arquitetura SDN, pois suporta a lógica de controle para gerar e manter a configuração da rede com base nas políticas definidas pelos operadores. Assim, a robustez do controlador é importante uma vez que lida diretamente com o desempenho da rede. Devido à sua importância, muitas pesquisas sobre o aprimoramento de projetos de controladores para melhoria de consistência, escalabilidade, flexibilidade, latência e disponibilidade têm sido constantemente desenvolvidas [55].
Os controladores podem ser categorizados em muitos aspectos. Do ponto de vista da arquitetura utilizada, o critério mais importante é se o controlador é centralizado ou distribuído. Um controlador centralizado é uma única entidade que gerencia todos os dispositivos de encaminhamento do plano de dados [77]. Como alguns representantes dessa categoria tem-se os controladores POX3, Beacon [78] e Floodlight4, todos desenvolvidos
concomitantemente a fim de oferecer o desempenho requerido por empresas e data centers.
Em um estudo apresentado por Erickson [78], foi verificado que um único controlador Beacon, executado em um servidor com 12 núcleos de processamento, foi capaz de suportar 12,8 milhões de novos fluxos por segundo com uma latência média de 24,7 microssegundos. De maneira similar, Tootoonchian et al. [79] conduziram avaliações quanto à estabilidade dos controladores NOX-MT, Maestro e Bacon. Uma rede contendo 100 mil hosts e 256 switches foi emulada para a realização dos testes. Os resultados indicaram que todos os controladores conseguiram lidar com pelo menos 50 mil novos fluxos por segundo. Um único controlador é capaz de lidar com um número surpreendente de novas solicitações de fluxo, e deve ser capaz de gerenciar redes de tamanho considerável. Além disso, os novos controladores em desenvolvimento têm como alvo o paralelismo de múltiplos núcleos de processamento (multithread) de poderosos servidores para garantir a escalabilidade até grandes cargas de trabalho de data center (cerca de 20 milhões de solicitações por segundo e até 5 mil switches) [80]. No entanto, o uso de apenas um
3 https://github.com/noxrepo/pox 4 http://www.projectfloodlight.org/
Capítulo 3. Software-defined Networking (SDN) 50
controlador, naturalmente, representa um ponto de falha bem como um gargalo quando utilizado em redes excessivamente grandes. Desse modo, vários controladores podem ser usados de forma colaborativa para reduzir a latência e aumentar a resiliência.
Contrário ao modelo centralizado, o plano de controle distribuído tenta aten- der aos requisitos de qualquer ambiente, de redes pequenas às grandes. Um controlador distribuído pode ser uma coleção centralizada de nós (cluster ) ou um conjunto de elemen- tos fisicamente separados. Enquanto a primeira configuração oferece baixa latência para estruturas que suportam grande volume de dados, por exemplo data centers, a segunda é mais tolerante a diferentes tipos de falhas [77]. Ainda, esses múltiplos controladores podem ser implementados de duas maneiras distintas. Na abordagem de plano de dados logicamente centralizado, os controladores sincronizam sua visão local sobre a rede uns com os outros. Dessa maneira, todos os controladores mantêm uma visão global e consis- tente da rede para tomar as melhores decisões de encaminhamento. No caso do plano de dados distribuídos fisicamente, não é necessário que cada controlador tenha conhecimento de todo o ambiente ao qual está inserido. Uma visão local já é suficiente para que ele desempenhe o seu papel no plano de controle.
Tabela 3.1 – Comparação entre controladores.
Controlador Categoria NBI API Linguagem Desenvolvedor
Beacon Centralizado REST API Java Univ. Stanford
Floodlight Centralizado RESTful API Java Big Switch Networks
Maestro Centralizado REST API Java Univ. Rice
NOX Centralizado ad-hoc API C++ Nicira
ONOS Distribuído RESTful API Java ON.Lab
OpenDaylight Distribuído REST, RESTCONF Java Linux Foundation
POX Centralizado ad-hoc API Python Nicira
RYU Centralizado adhoc API Python NTT
A Tabela 3.1 apresenta a síntese de alguns dos controladores mais populares do mercado. As informações destacam a categoria em relação à arquitetura, tipo de in- terface de comunicação, linguagem de programação usada e a entidade responsável pela manutenção do desenvolvimento de cada controlador.
3.2.6.1 Interfaces Eastbound e Westbound
As interfaces eastbound e westbound são API usadas por controladores distri- buídos. Suas principais funções incluem a comunicação entre os controladores, algoritmos para manutenção da consistência dos dados, recursos de monitoramento e notificação. Como exemplo, as interfaces eastbound e westbound são usadas para verificar se um con-
Capítulo 3. Software-defined Networking (SDN) 51
trolador está em funcionamento ou notificar a transferência do controle de um conjunto de dispositivos do plano de dados para outro controlador.
Para garantir a compatibilidade e a interoperabilidade entre os diferentes con- troladores, é necessário que essas interfaces também sejam definidas por meio de padrões. Assim, as soluções propostas podem ser usadas de maneira orquestrada e interoperável a fim de construir planos de controle distribuídos mais escalonáveis e confiáveis. Pensando dessa forma, a arquitetura SDN estabeleceu requisitos comuns para coordenar comporta- mentos entre os controladores e trocar informações de controle em vários domínios SDN.