A rede definida por software (em Inglês, Software Defined Networking ou SDN) é um novo paradigma para redesenhar as redes de telecomunicações considerando o ponto de vista da engenharia de software. O argumento é que as redes atuais são essencialmente projetadas para “dominar a complexidade” por trás das tecnologias existentes, ao invés de “extrair simplicidade” das lições aprendidas [1]. Scott Shenker, um dos criadores da ideia, defende que as abstrações desempenham um grande papel na ciência da computação, protegendo o software de alto nível da complexidade existente nos níveis mais baixos. Ou seja, uma abstração nada mais é do que uma caixa preta com interfaces. O que acontece dentro da caixa preta é escondido, independente de outras funções. O que importa são as interfaces. Assim, por que não definir boas abstrações para redes seguindo esse modelo? Foi isso que despertou a criação das redes programáveis atuais.
Neste contexto, SDN significa repensar as arquiteturas de rede considerando o importante papel das abstrações [1]. Vale notar que no domínio de SDN, o termo "definido por software" (ou controlado por software) significa que alguma funcionalidade é configurada, reprogramada, alterada de acordo com algum software de controle. Assim, SDN significa estabelecer redes onde as funcionalidades dos equipamentos são controladas por softwares de controle fora dos mesmos. Esta definição inclui qualquer equipamento que possa ser usado para fazer rede, assim como qualquer funcionalidade de rede. De forma abrangente, SDN pode ser usada para redesenhar o plano de dados e controle em diversas tecnologias.
A primeira aplicação de SDN foi no desacoplamento da implementação do plano de controle do plano de dados nos comutadores das redes de pacotes. Esses passam a ser controlados por um software controlador que centraliza as decisões de encaminhamento de tráfego conforme a necessidade das aplicações. As aplicações podem configurar como preferem que os pacotes sejam encaminhados pelos nós da rede. Um protocolo de controle é utilizado para configurar uma tabela de encaminhamento de pacotes nos nós comutadores da rede através de uma interface denominada de interface sul do controlador. A tabela de encaminhamento contém um classificador de pacotes, um conjunto de ações que podem ser executadas quando um pacote encaixa em alguma classificação disponível e estatísticas. O controlador pode criar uma nova linha na tabela, portanto definindo como os pacotes são classificados e as ações condizentes. É possível criar uma regra para encaminhar pacotes que não se encaixam em outras regras para o controlador. O controlador solicita via protocolo de controle a criação de uma nova linha na tabela para atender esses pacotes. O mais conhecido protocolo de controle com esse objetivo é o OpenFlow.
As origens da SDN remontam ao projeto Ethane desenvolvido no departamento de ciências da computação de Universidade de Stanford. O projeto do comutador Ethane levou posteriormente ao desenvolvimento do protocolo de controle e do comutador de arquitetura aberta OpenFlow. Isso mesmo, os comutadores OpenFlow seguem uma arquitetura aberta conhecida por todos. Fora da universidade, as primeiras implantações com viés comercial foram feitas pela empresa Nicira em 2010 para controlar um comutador virtual chamado OpenvSwitch (OvS) desenvolvido pela Onix, com participação da NTT e do Google. A Nicira foi fundada em 2007 pelos professores Nick McKeown e Scott Shenker, e pelo aluno de doutorado Martin Casado. Em 2011, foi criada a Open Networking Foundation (ONF) [1] visando promover a SDN com OpenFlow. Em 2012, a VMware adquiriu a Nicira por US $ 1,26 bilhões.
Qual a relação com de SDN com a virtualização de redes?
SDN está relacionada a outra ideia chamada Network-as-a-Service (NaaS). Significa exportar e virtualizar os recursos de uma rede física como um serviço, ou seja, através de programas de computador. De forma mais especifica, significa ofertar fatias isoladas do serviço de encaminhamento de tráfego através da interface norte de um controlador SDN. Dessa forma, outros serviços ou aplicações da rede podem contratar o encaminhamento de tráfego em diversos nós, criando uma rede virtual que as atende. Para isso, devem interagir com um ou mais controladores SDN criando fatias isoladas da rede física. Esse é o famoso fatiamento da rede física. Cada fatia tem suas regras implementadas nos comutadores via um controlador SDN, atendendo demandas específicas das aplicações. São as chamadas Application-Aware Networks. As aplicações enxergam redes virtuais, que na prática são configurações de encaminhamento em comutadores físicos Ethernet, Wi-Fi ou outros. SDN tem sido aplicada em data centers para otimizar o fluxo de tráfego entre servidores e em Internet das Coisas para configurar o encaminhamento de tráfego entre nós sensores, atuadores e gateways. SDN também é utilizada nas redes de longa distância onde recebe o nome de Software Defined Wide Area Network (SDWAN). Hoje, se utiliza SDWAN em redes híbridas terrestre/satélite, permitindo a criação de fatias que passam por terminais e gateways satelitais. Um recurso fundamental para viabilizar as novas constelações de orbita baixa, dado que os terminais mudam de satélite periodicamente devido a variação de cobertura. Em resumo, SDN permite a criação de operadoras virtuais que contratam dinamicamente redes físicas como serviços. Alguns projetos já demonstraram a criação de fatias físicas para prover operadores virtuais em 90 minutos. Ou seja, em 90 minutos toda a infraestrutura física é reservada e configurada para atender um operador virtual. Tudo via software, com o mínimo de intervenção humana.
O que mais existe de SDN além do OpenFlow?
Existem muitas outras abordagens. Mas, uma que gostaria de comentar aqui é a Programming Protocol-Independent Packet Processors (P4). P4 é uma solução para configurar o plano de dados de comutadores de pacotes em hardware. Para tanto, oferece recursos de parser de cabeçalhos e tabelas Match-Action, que servem para identificar fluxos de pacotes e aplicar ações correspondentes. Permite também criar uma interface no plano de controle conforme a estrutura do plano de dados implementada no comutador de pacotes.
Nesse momento, você deve estar se perguntando qual a relação entre P4 e OpenFlow? A resposta é que um comutador OpenFlow pode ser criado usando P4. Enquanto o OpenFlow é um protocolo que permite popular um conjunto de tabelas padronizadas implementadas em hardware em um comutador compatível que segue uma estrutura padrão para o plano de dados, o P4 endereça a necessidade de programar o plano de dados livremente, permitindo que programadores definam como os comutadores processam pacotes, que tabelas são mantidas e como é a interface que deve ser usada para popular as tabelas. As tabelas podem ser populadas por um controlador ou por um OS local. Assim sendo, OpenFlow é um dos muitos programas possíveis em P4, descrevendo como o encaminhamento no plano de dados funciona e que interface deve ser usada para popular as tabelas dos comutadores. P4 abre a possibilidade de criarmos inúmeros protocolos de controle de rede, definindo sintaxes e semânticas ajustáveis via troca de firmware em equipamentos que suportem P4. O Barefoot Tofino é um dos comutadores P4 disponíveis hoje no mercado [2]. P4 hoje faz parte da ONF.
Um exemplo de aplicação do P4 é na 5ª geração de comunicações móveis (5G). De forma geral, o encaminhamento eletrônico de tráfego do 5G pode ser implementado usando P4 tanto na RAN, quanto no core. Comutadores genéricos poderiam encaminhar tráfego heterogêneo vindo de diversas redes de acesso. Isso permitiria que tráfegos heterogêneos provenientes de Internet das Coisas, redes anteriores (3G/4G), redes industriais, smart grid, etc. fossem acomodados através de comutadores expansíveis implementados em P4. Nesse momento, estou trabalhando em um projeto de pesquisa com P4 no Information and Communications Technologies (ICT) Lab. do Instituto Nacional de Telecomunicações (Inatel), em Santa Rita do Sapucaí, MG. O projeto integra 4 arquiteturas de Internet (a corrente que usa TCP/IP, e três alternativas: NovaGenesis, ETArch e NDN) via um comutador P4. O parser desse comutador identifica qual a pilha de protocolos de um dado pacote, entregando os pacotes para a implementação do plano de dados correspondente. Nesse projeto denominado Future Internet Interconnection Point (FIXP), os comutadores encaminham tráfego de diversas pilhas de protocolos em paralelo. Se não existem regras para encaminhar um certo pacote, um controlador que implementa o plano de controle correspondente é acionado. Veja o artigo desse trabalho na referência [3]. O projeto chama-se: “Alavancando a Internet do Futuro no Brasil através da Coexistência e Interconexão de Múltiplas Arquiteturas” (2015/24518-4). Ele é financiado via um acordo de cooperação científica e tecnológica entre FAPESP, MCTIC e CGI.
Como funciona a SDN tecnicamente falando?
O paradigma SDN de Shenker et al. [1] baseia-se na premissa de que nunca desenvolvemos as abstrações certas para o trabalho em rede. Assim, a SDN propõe quatro abstrações para simplificar o controle de rede: (i) encaminhamento; (ii) redução dos estados distribuídos; (iii) configuração; e (iv) especificação. A abstração de encaminhamento engloba um modelo de encaminhamento de pacotes flexível, controlado por software. A abstração de redução dos estados distribuídos compreende um programa de controle centralizado que opera sobre uma visão resumida da rede. Isso evita a complicada abordagem de estados distribuídos usada hoje em muitas redes. Ou seja, muitas implementações distribuídas do plano de controle. A saída do programa de controle é um mapa de configuração da rede. Para criar a visualização de rede necessária, é utilizado um sistema operacional de rede (em Inglês, Network Operating System ou NOS). O NOS se comunica com o equipamento de encaminhamento para obter informações do estado, bem como para enviar controles - a realização da abstração de configuração. A abstração da especificação permite a geração de configurações abstratas (virtuais) para dispositivos e redes. Essas configurações abstratas precisam ser mapeadas para as físicas. É assim que são criadas as fatias das redes físicas.
Um comutador OpenFlow implementa um pipeline de pacotes que contém uma ou mais tabelas de fluxo, cada qual composta de múltiplas entradas. O pipeline especifica como os pacotes interagem com essas tabelas. Quando processado por uma tabela de fluxo, o pacote é comparado com as entradas dessa tabela visando selecionar uma entrada adequada. Se uma entrada de fluxo for localizada, o conjunto de instruções incluído nessa entrada de fluxo é executado. Estas instruções podem direcionar explicitamente o pacote para outra tabela de fluxo, onde o mesmo processo é repetido. Se a entrada de fluxo correspondente não direcionar pacotes para outra tabela de fluxo, o processamento de pipeline termina nesta tabela. Quando o processamento do pipeline é interrompido, o pacote é processado com seu conjunto de ações associadas e encaminhado para a saída. Em resumo, os pacotes são classificados conforme entradas na tabela. Ocorrendo correspondência a uma delas, o pacotes recebe então as ações associadas a essa entrada.
O controlador OF pode controlar tabelas em switches físicos e/ou virtuais, e.g. OpenvSwitch. O ciclo de vida de entidades virtuais passa pela configuração de fatias de rede, que são criadas via configuração de encaminhamento em tabelas de fluxo. No meu próximo artigo vou mostrar como um orquestrador de arquitetura Network Function Virtualization (NFV) ou outras aplicações interagem com um controlador SDN para refletir configurações necessárias das aplicações no encaminhamento da rede virtual. Vou discutir a virtualização de funções de rede e como SDN e NFV trabalham em conjunto, quais os impactos disso nas operadoras de telecomunicações e para onde estamos indo com o 5G.
* Antonio Marcos Alberti é engenheiro, professor, coordenador do Information and Communications Technologies (ICT) Laboratory do Inatel e programador C/C++. É doutor em Eletrônica e Telecomunicações pela Unicamp e pós-doutor pelo Electronics and Telecommunications Research Institute (ETRI) da Coréia do Sul. Autor de mais de 100 artigos científicos. Já ministrou mais de 60 palestras sobre tecnologia e suas disrupções, incluindo HackTown, Futurecom, Exponential Conference, QCon, TEDxInatel, Pint of Science, Ciência no Boteco, etc. Colunista do Olhar Digital, EngenhariaÉ e Futurecom. Pai da arquitetura NovaGenesis. Contribuiu para documento de requisitos para Internet do Futuro na Coréia do Sul e nas discussões iniciais do Plano Nacional de M2M/IoT. Hacker de tendências e consultor.
Referências:
[1] ONF, Open networking foundation (2012). URL: www.opennetworking.org
[2] Barefoot Tofino. URL: https://barefootnetworks.com/products/brief-tofino/
[3] WPEIF 2019, X Workshop de Pesquisa Experimental da Internet do Futuro (10: 2019: Gramado, RS), URL: http://sbrc2019.sbc.org.br/wp-content/uploads/2019/05/wpeif2019.pdf
