Redes Definidas por Software

Redes Definidas por Software

Redes Definidas por Software (SDN – do inglês Software Defined Networking [1]) é um paradigma que está cada vez mais popular. A ideia é desassociar o plano do controle do plano dos dados, sobretudo mantendo o controle em um software controlador/gerenciador.

Foi adotado o OpenFlow [2], certamente  para conseguir tal objetivo. Foi proposto como uma ferramenta para permitir inovação na rede. Os benefícios de usar OpenFlow permitiriam aos pesquisadores rodarem experimentos em hardware real sem interferir no tráfego.

O SDN consiste em desacoplar o controle dos dados em si, enquanto o OpenFlow descreve como um software controlador e um dispositivo na rede devem estabelecer comunicação para atender ao formato do SDN.

Motivação para o SDN

Segundo Adrian Lara [3], após a sua utilização para o SDN o OpenFlow acaba por ter um incremento em seu propósito, servindo para padronizar a comunicação entre hardwares (inicialmente switches) e o software controlador,com a finalidade de contemplar a arquitetura SDN.

O OpenFlow é mantido e gerenciado pelo Open Networking Foundation (ONF), que identificou a dificuldade da comunidade de pesquisa em rede para realizar testes de novas ideias com os hardwares atuais. Tal dificuldade provém principalmente da forma como o código que roda dentro dos dispositivos é disposto, não podendo ser modificado sem autorização do proprietário, além da própria disposição da infraestrutura da rede, estando “ossificada”, tornando complicado testes de novas ideias de rede com configurações de tráfego realistas.

Ocasionalmente, a manutenção ou alteração em equipamentos proprietários requer um profissional especializado. Um fator que muitas vezes inviabiliza tal iniciativa. Com uma rede definida por software, é possível moldar o tráfego alterando as regras de redirecionamento, sem entrar em contato direto com o equipamento.

O destaque do SDN é a possibilidade da reconfiguração de toda a rede, acompanhando a demanda de serviços e utilização da rede.

A motivação do SDN é retirar a complexidade do hardware e permitir flexibilidade e inovação no software. Em resultante, o hardware é favorecido, tendendo a se tornar mais simplificado, focando somente na realização do encaminhamento do tráfego. Como contraposição, o software se torna responsável por gerenciar a rede e a forma como os dispositivos encaminham o tráfego, sendo capaz de alterar as regras de encaminhamento que antes eram fixas nos dispositivos.

Composição SDN-OpenFlow

Algumas características podem ser citadas para esclarecer a relação entre SDN e OpenFlow.

O SDN dá ao usuário uma forma de abstração do estado de toda a rede e o OpenFlow abstrai os componentes da rede. O OpenFlow pode ser encarado como uma especificação quando se trata de padronizar os dispositivos e é encarado como uma arquitetura se visto sob o contexto de uma rede inteira.

Uma arquitetura SDN-OpenFlow consiste de três componentes principais: um hardware compatível com OpenFlow e um software controlador que são intermediados pelo terceiro elemento, um canal seguro. Esse é o ponto onde o protocolo OpenFlow entra, lidando com o formato do encaminhamento das mensagens passadas entre o plano de controle e o hardware OpenFlow.

Uma tendência comum para as diversificadas formas de implantação do OpenFlow é explorar a forma de atualizar dinamicamente as regras de encaminhamento dos pacotes. Possuir um gerenciador sensível à rede possibilita ao software controlador encaminhar de forma dinâmica o tráfego, ajustando-se às necessidades [3].

Arquitetura SDN-OpenFlow – Adaptada [1]

SDN trouxe a tona capacidades únicas que permitem diversas formas para o gerenciamento de redes.

[1] Software-defined networking (sdn) definition,

https://www.opennetworking.org/sdn-resources/sdn-definition. Acessado em 10 de Fevereiro de 2017.

[2]  Openflow. https://www.opennetworking.org/sdn-resources/openflow.

Acessado em 10 de Fevereiro de 2017.

[3]  Adrian Lara. Using software-defined networking to improve campus, transport and future internet architectures. 2015.

Por Eduardo Henrique – Analista e Desenvolvedor de Sistema da Weblynx