Mesures prises par la Direction de la Sécurité de l’Aviation Civile (DSAC) et son exploitant pour lutter

como novo paradigma de redes, faz-se necessária uma abordagem mais aprofundada sobre os controladores SDN, uma vez que estes possuem papel crítico na arquitetura. Sendo esta abordagem realizada na próxima Seção.

2.3

Controladores

Um dos principais componentes da arquitetura SDN, deve possuir desde os recursos necessários para a comunicação e demais necessidades da rede até uma interface apropriada para que aplicações possam utilizá-lo como meio para controlar os recursos de rede disponíveis. No decorrer desta secção são abordadas algumas propostas de controladores, criados com propósitos acadêmicos e comerciais.

O controlador NOX (GUDE et al., 2008) foi o primeiro controlador OpenFlow a ser desenvolvido. Suportando originalmente as linguagens C++ e Python, possuía as funcionalidades necessárias ao funcionamento do protocolo Openflow na versão 1.0. Originalmente criado pela Nicira Networks, agora pertencente à VMware e dividiu-se basicamente em três vertentes:

 NOX clássico - Refere-se à versão original do NOX, atualmente distribuída sob a

licença GPL.

 Novo NOX - Nome utilizado para realizar referência a nova implementação do NOX,

com suporte apenas à C++, possui menos funcionalidades nativas, mas é mais rápida e tem uma melhor base de códigos.

 POX - Versão desenvolvida na linguagem de programação Python, adquirindo um

volume significativo de adeptos.

O controlador FlowVisor (SHERWOOD et al., 2009) foi desenvolvido em uma parceria entre a Deutshe Telekom, a Universidade de Stanford e a Nicira Networks. Consistindo em um controlador OpenFlow especializado, atua como um proxy entre a comunicação de controladores convidados e switches OpenFlow em uma rede, criando a capacidade de fracionar os recursos disponíveis em segmentos de rede controláveis (slices).

Através da utilização do protocolo OpenFlow e de sua arquitetura o FlowVisor é capaz de disponibilizar segmentos da rede física real sem a necessidade de promover alterações nos controladores convidados, transparecendo para estes que as configurações estão sendo realizadas diretamente nos dispositivos de rede, conforme Figura 2.5.

Para realizar a separação dos slices o FlowVisor intercepta as mensagens trocadas entre controladores convidados e switches OpenFlow, permitindo aos controladores ver e modificar apenas os recursos dos segmentos aos quais estes tem acesso.

Os segmentos de rede criados pelo FlowVisor são definidos com isolamento em cinco dimensões específicas:

2.3. CONTROLADORES 38

Figura 2.5: Representação da arquitetura do controlador FlowVisor.

Fonte: (SHERWOOD et al., 2009).

 Largura de Banda: De maneira geral refere-se a quanto de cada link real poderá ser

consumido por um segmento.

 Topologia: Os controladores convidados devem possuir a capacidade de acessar

apenas os dispositivos permitidos, ou seja, caso um grupo de ativos não esteja no segmento controlado este deve ser isolado dos ativos no segmento em questão.

 Tráfego: Em um sentido geral um tráfego qualquer pode ser associado a um segmento,

seja por endereços de origem e destino, protocolo, etc.

 Central Processing Unit(CPU) dos dispositivos: Os recursos de processamento dos

dispositivos também devem ser divididos isoladamente, de acordo com as permissões de cada segmento. Esta decisão foi empregada para evitar que operações descritas em Sherwood et al. (2009), que consomem mais recursos de CPU, possam romper o isolamento entre os segmentos.

 Tabelas de encaminhamento: As tabelas de encaminhamento de cada controlador

devem ser isoladas entre si. Para mapear e conferir controle sobre isto o FlowVisor utiliza limitações sobre a área das tabelas de fluxos dos dispositivos que podem ser acessadas por cada controlador convidado, conforme Sherwood et al. (2009), fazendo

2.3. CONTROLADORES 39 com que cada controlador convidado acredite estar manipulando tabelas completas e não frações de tabelas.

O isolamento de recursos como CPU e largura de banda na época de criação do con- trolador eram indisponíveis na versão do protocolo OpenFlow. Para suprir estas necessidades os autores mapearam tecnologias presentes em redes tradicionais, como bits de priorização de VLANs ou implementações de QoS, avaliando o impacto das opções selecionadas.

O Beacon é um controlador SDN open source escrito em Java e desenvolvido no ano de 2010. Conforme Erickson (2013), foi amplamente utilizado para ensino, pesquisa e como base para outros controladores, como o FloodLight.

O desenvolvimento do Beacon teve três focos principais:

 Melhorar a produtividade dos desenvolvedores - Várias escolhas estratégicas do

projeto, desde a linguagem Java até questões arquiteturais do controlador, foram realizadas em prol do aumento na eficiência da produção de aplicações SDN.

 Modularidade em tempo de execução - Um dos pioneiros em focar a capacidade

de adição e remoção de aplicações SDN em tempo de execução, criando uma série de novas oportunidades e elevando a disponibilidade do serviço do controlador como um todo. Utiliza para tanto a tecnologia Open Services Gateway Initiative (OSGI), adotada também por outros controladores criados posteriormente, como o OpenDaylight, por exemplo.

 Alta performance - Projetado com capacidades voltadas para alta performance,

como multithread em sua estrutura, também possui mecanismos para evitar problemas correlatos, como por exemplo condições de corrida para o acesso aos recursos.

2.3.1

Controlador Opendaylight

Introduzido em Medved et al. (2014), os autores do controlador Opendaylight identi- ficaram que um controlador SDN deveria possuir as seguintes características:

 Flexibilidade - O controlador deve ser capaz de comportar uma grande variedade de

aplicações, enquanto que as aplicações devem utilizar um framework e um modelo de programação comuns entre si. Além disso, devem proporcionar Application Programming Interfaces (APIs) consistentes para os clientes, fomentando atividades como integração de sistemas e orquestração de aplicações em alto nível.

 Processo de desenvolvimento escalável - Um controlador deve proporcionar uma

arquitetura apta ao desenvolvimento de soluções que possam atuar nos diversos cenários onde são presentes redes SDN.

2.3. CONTROLADORES 40

 Extensibilidade em tempo de execução - Um controlador SDN deve proporcionar a

adição e remoção de recursos de forma dinâmica, em tempo de execução, permitindo modificações inerentes às redes SDN mesmo em ambientes que demandam alta disponibilidade e, portanto, não toleram interrupções constantes ou desnecessárias.

 Alto desempenho em ambientes escaláveis - Em um contexto de redes de comu-

nicação altamente expansíveis, sendo este acentuado por tecnologias como Cloud Computing, um controlador SDN não pode atuar como entrave ao funcionamento das soluções em alta performance. Neste contexto, o controlador deve ser capaz de geren- ciar adequadamente as mudanças ocorridas na topologia, bem como transparecer para as aplicações SDN vantagens decorrentes destas mudanças.

Os controladores SDN tradicionais implementam OpenFlow como o único protocolo disponível para o contato com a rede, em virtude de sua aceitação e capacidade de prover operação em redes SDN. Todavia, conforme Medved et al. (2014), os criadores do controlador OpenDaylight compreendem que a separação entre os planos de controle e encaminhamento da arquitetura SDN é importante, porém acreditam que SDN vai além do que é fornecido pelo protocolo OpenFlow, apontando dois motivos principais para isto:

 O protocolo OpenFlow obtém e manipula informações de rede que sejam diretamente

ligadas à função de encaminhamento de pacotes, em detrimento de uma grande gama de outras informações de rede que podem fornecer subsídio para aplicações SDN. Fato este que tem sido abordado pela academia através de extensões para o protocolo OpenFlow capazes atuar em novas possibilidades (MEKKY et al., 2014).

 Existem diversas formas de programar redes além da interação promovida pelo

protocolo OpenFlow, como Simple Network Management Protocol (SNMP),Border Gateway Protocol(BGP), ou até mesmo estruturas proprietárias, não sendo interes- sante promover a limitação de uma gama de opções para apenas uma.

Originalmente inspirado pelo controlador Beacon, o OpenDayLight herdou deste o suporte à modularização baseada em OSGI. Logo, a instalação de componentes no controlador OpenDaylight é realizada através de bundles OSGI, abordados na arquitetura do controlador como plugins.

O controlador OpenDaylight foi desenvolvido com a premissa de operar na intersecção entre três tecnologias emergentes, sendo estas:

 SDN - Conforme comentado anteriormente, a tecnologia SDN possui diversas carac-

terísticas favoráveis ao desenvolvimento de novos protocolos e aplicações de rede, bem como fomentar a própria evolução das redes atuais.

2.3. CONTROLADORES 41

 Model Driven Software Engeneering (MDSE) - Advindo da engenharia de software,

o MDSE consiste em um framework baseado nos relacionamentos entre diferentes modelos, gerando padrões que permitem a criação de modelos de software e, por extensão, produção de códigos dos modelos. MDSE também prevê abstrações que permitem englobar qualquer linguagem para modelar específica.

 Model driven network management - Conforme Medved et al. (2014), consiste em

uma proposta empregada no domínio de redes para descrever as funcionalidades de componentes inerentes a este, desde dispositivos até APIs. Para realizar estas tarefas foram selecionados os protocolos NETCONF (MEDVED et al., 2014) e RESTCONF (MEDVED et al., 2014), como linguagem para modelar foi selecionada uma das mais proeminentes do domínio de redes, a linguagem YANG (MEDVED et al., 2014). Desde seu início, conforme aponta Medved et al. (2014), o controlador OpenDaylight foi implementado com um paradigma inovador chamado Service Abstraction Layer (SAL), que possuía por função separar dois tipos de componentes, os plugins de protocolos southbound dos pluginsde aplicações e serviços da northbound.

Os plugins e protocolos southbound possuem como função prover a comunicação com os ativos de rede, neles são programadas funções como o próprio OpenFlow. Enquanto que os pluginse protocolos northbound estão diretamente ligados ao controle da rede e às aplicações SDN, um exemplo seria o plugin do VTN Manager, abordado apropriadamente na seção 2.4.

Uma representação do controlador contendo a southbound, SAL e a northbound pode ser vista na figura 2.6.

A arquitetura SAL original, referida em Medved et al. (2014) como "API-Driven SAL" ou AD-SAL, foi substituída durante o desenvolvimento do controlador em virtude de uma limitação evidente: os desenvolvedores tinham de definir as APIs utilizadas pelos plugins e produzir a adaptação entre os plugins da northbound e southbound.

Para superar as limitações presentes na AD-SAL foi implementada uma nova arquitetura, a "Model-Driven" SAL, assim designada por ser alinhada às estratégias de automação de desenvolvimento da MDSE e às tecnologias relatadas no tópico sobre Model driven network management.

O controlador OpenDayLight contribui para o avanço do estado da arte em redes SDN, combinando um ambiente de desenvolvimento versátil, composto por tecnologias e padrões que fomentam desenvolvimento ágil e colaboração da comunidade científica.

No desenvolvimento deste trabalho foi empregada a última versão estável disponível à época, sendo esta a Release 2 da versão Lithium do controlador. A estrutura do controlador nesta versão pode ser observada na imagem 2.7.

As opções fornecidas pelo controlador OpenDaylight permitem a criação de propostas inovadoras para a operação e gerenciamento de redes SDN. Dentre estas propostas, foi empregada a tecnologia de Virtual Tenant Networks, abordada na próxima Seção.