A tecnologia de rede definida por software ( SDN ) é uma abordagem ao gerenciamento

de rede que permite uma configuração de rede dinâmica e programaticamente eficiente para

melhorar o desempenho e o monitoramento da rede, tornando-a mais parecida com a
computação em nuvem do que com o gerenciamento de rede tradicional. [1] O SDN destina-se a
abordar o fato de que a arquitetura estática das redes tradicionais é descentralizada e
complexa, enquanto as redes atuais exigem mais flexibilidade e fácil solução de problemas. O
SDN tenta centralizar a inteligência de rede em um componente de rede, desassociando o
processo de encaminhamento de pacotes de rede (plano de dados) do processo de roteamento
(plano de controle). O plano de controleconsiste em um ou mais controladores que são
considerados o cérebro da rede SDN, onde toda a inteligência é incorporada. No entanto, a
centralização inteligente tem suas próprias desvantagens quando se trata de
segurança, [1] escalabilidade e elasticidade [1] e esse é o principal problema do SDN.
O SDN era comumente associado ao protocolo OpenFlow (para comunicação remota com
elementos do plano de rede com o objetivo de determinar o caminho
dos pacotes de rede entre os comutadores de rede ) desde o surgimento deste último em 2011.
No entanto, desde 2012 [2] [3] OpenFlow para muitos empresas não é mais uma solução
exclusiva, eles adicionaram técnicas proprietárias. Isso inclui o Open Network Environment
da Cisco Systems e a plataforma de virtualização de rede da Nicira .
A SD-WAN aplica tecnologia semelhante a uma rede de longa distância (WAN). [4]
Atualmente, a tecnologia SDN está disponível para aplicativos de controle industrial que
requerem failover extremamente rápido. Uma empresa possui failover 100x mais rápido para
processos críticos (failover em menos de 100 μs, em comparação com 10 ms para redes
tradicionais), juntamente com a eliminação de certas vulnerabilidades cibernéticas associadas
aos comutadores de gerenciamento de rede tradicionais.
A pesquisa da SDN continua, pois muitos emuladores estão sendo desenvolvidos para fins de
pesquisa, como vSDNEmul, [5] EstiNet, [6] Mininet [7] etc.

O histórico dos princípios SDN pode ser rastreado até a separação do plano de controle e dados
usado pela primeira vez na rede telefônica pública comutada como uma maneira de simplificar
o provisionamento e o gerenciamento muito antes de essa arquitetura começar a ser usada nas
redes de dados.
A Força-Tarefa de Engenharia da Internet (IETF) começou a considerar várias maneiras de
dissociar as funções de controle e encaminhamento em um padrão de interface proposto
publicado em 2004 apropriadamente denominado "Encaminhamento e separação de elementos
de controle" (ForCES). [8] O grupo de trabalho do ForCES também propôs uma arquitetura
SoftRouter associada. [9] Os padrões iniciais adicionais da IETF que buscavam separar o controle
dos dados incluem o Linux Netlink como um protocolo de serviços IP [10] e uma arquitetura
baseada em elemento de computação de caminho (PCE). [11]
Essas primeiras tentativas falharam em ganhar força por dois motivos. Uma é que muitos na
comunidade da Internet viam a separação entre controle e dados como arriscados,
principalmente devido ao potencial de falha no plano de controle. A segunda é que os
fornecedores estavam preocupados que a criação de APIs (interfaces de programação de
aplicativos) padrão entre os planos de controle e dados resultasse em maior concorrência.
O uso de software de código aberto em arquiteturas de controle dividido / plano de dados tem
suas raízes no projeto Ethane no departamento de ciências da computação de Stanford. O
design simples do switch do Ethane levou à criação do OpenFlow. [12] Uma API para OpenFlow
foi criada pela primeira vez em 2008. [13] Nesse mesmo ano, testemunhamos a criação do NOX -
um sistema operacional para redes. [14]
O trabalho no OpenFlow continuou em Stanford, inclusive com a criação de bancos de ensaio
para avaliar o uso do protocolo em uma única rede de campus, bem como na WAN como uma
espinha dorsal para conectar vários campi. [15] Em ambientes acadêmicos, havia algumas redes
de pesquisa e produção baseadas em switches OpenFlow da NEC e Hewlett-Packard ; bem
como com base nas caixas brancas da Quanta Computer , a partir de 2009. [16]
Além da academia, as primeiras implantações foram realizadas por Nicira em 2010 para
controlar o OVS da Onix, co-desenvolvido com a NTT e o Google. Uma implantação notável
foi a implantação B4 do Google em 2012. [17] [18] Mais tarde, o Google reconheceu suas
primeiras implantações OpenFlow com Onix em seus datacenters ao mesmo tempo. [19] Outra
grande implantação conhecida é a China Mobile . [20]
A Open Networking Foundation foi fundada em 2011 para promover SDN e OpenFlow .
No Interop and Tech Field Day de 2014, a rede definida por software foi demonstrada
pela Avaya usando a ponte de caminho mais curto ( IEEE 802.1aq ) e o OpenStack como um
campus automatizado, estendendo a automação do data center para o dispositivo final,
removendo o provisionamento manual da entrega de serviços . [21] [22]

Conceito 
As arquiteturas SDN separam as funções de controle e encaminhamento de rede, permitindo
que o controle de rede se torne diretamente programável e a infraestrutura subjacente seja
abstraída dos aplicativos e serviços de rede. [23]
O protocolo OpenFlow pode ser usado em tecnologias SDN. A arquitetura SDN é:

 Diretamente programável : O controle de rede é diretamente programável porque é

desacoplado das funções de encaminhamento.
 Ágil : abstrair o controle do encaminhamento permite que os administradores ajustem
dinamicamente o fluxo de tráfego em toda a rede para atender às novas necessidades.
 Gerenciado centralmente : a inteligência de rede é (logicamente) centralizada nos
controladores SDN baseados em software que mantêm uma visão global da rede, que
aparece para aplicativos e mecanismos de política como um único switch lógico.
 Programaticamente configurado : o SDN permite que os gerentes de rede configurem,
gerenciem, protejam e otimizem os recursos de rede rapidamente, por meio de programas
SDN dinâmicos e automatizados, que eles podem escrever por conta própria, porque os
programas não dependem de software proprietário.
 Baseado em padrões abertos e neutro em fornecedores : Quando implementado em
padrões abertos, o SDN simplifica o design e a operação da rede, pois as instruções são
fornecidas pelos controladores SDN em vez de vários dispositivos e protocolos específicos
do fornecedor.

A necessidade de uma nova arquitetura de rede 

A explosão de conteúdo e dispositivos móveis, virtualização de servidores e o advento dos
serviços em nuvem estão entre as tendências que impulsionam o setor de redes a reexaminar
as arquiteturas de rede tradicionais. [24] Muitas redes convencionais são hierárquicas,
construídas com camadas de switches Ethernet dispostas em uma estrutura em árvore. Esse
design fazia sentido quando a computação cliente-servidor era dominante, mas essa arquitetura
estática não é adequada às necessidades dinâmicas de computação e armazenamento dos
atuais data centers corporativos, campi e ambientes de operadora. [25] Algumas das principais
tendências da computação que direcionam a necessidade de um novo paradigma de rede
incluem:
Alterando padrões de tráfego
No data center corporativo, os padrões de tráfego mudaram significativamente. Ao
contrário dos aplicativos cliente-servidor, nos quais a maior parte da comunicação
ocorre entre um cliente e um servidor, os aplicativos atuais acessam bancos de dados e
servidores diferentes, criando uma enxurrada de tráfego máquina-máquina "leste-
oeste" antes de retornar dados ao final dispositivo de usuário no padrão de tráfego
clássico "norte-sul". Ao mesmo tempo, os usuários estão alterando os padrões de
tráfego de rede à medida que tentam acessar conteúdo e aplicativos corporativos a
partir de qualquer tipo de dispositivo (inclusive o próprio), conectando-se de qualquer
lugar e a qualquer momento. Por fim, muitos gerentes de data centers corporativos
estão contemplando um modelo de computação de utilidade, que pode incluir uma
nuvem privada, nuvem pública ou uma mistura de ambos,
A "consumerização da TI"
Os usuários estão cada vez mais empregando dispositivos pessoais móveis, como
smartphones, tablets e notebooks para acessar a rede corporativa. A TI está sob
pressão para acomodar esses dispositivos pessoais de maneira refinada, protegendo
dados corporativos e propriedade intelectual e cumprindo os requisitos de
conformidade.
A ascensão dos serviços em nuvem
As empresas adotaram com entusiasmo os serviços de nuvem pública e privada,
resultando em um crescimento sem precedentes desses serviços. As unidades de
negócios corporativas agora desejam agilidade para acessar aplicativos, infraestrutura e
outros recursos de TI sob demanda e à la carte. Para aumentar a complexidade, o
planejamento da TI para serviços em nuvem deve ser realizado em um ambiente com
requisitos de segurança, conformidade e auditoria aumentados, além de
reorganizações, consolidações e fusões de negócios que podem alterar as premissas da
noite para o dia. O fornecimento de provisionamento de autoatendimento, seja em
nuvem pública ou privada, requer dimensionamento elástico dos recursos de
computação, armazenamento e rede, idealmente de um ponto de vista comum e com
um conjunto comum de ferramentas.
"Big data" significa mais largura de banda
O tratamento dos "big data" ou mega conjuntos de dados de hoje exige um enorme
processamento paralelo em milhares de servidores, todos os quais precisam de
conexões diretas entre si. O aumento de mega conjuntos de dados está alimentando
uma demanda constante por capacidade de rede adicional no data center. Os
operadores de redes de datacenter em superescala enfrentam a difícil tarefa de escalar
a rede para um tamanho anteriormente inimaginável, mantendo a conectividade de
qualquer um a qualquer sem quebrar. [26]

Componentes de arquitetura 

Uma visão geral de alto nível da arquitetura de rede definida por software

A lista a seguir define e explica os componentes da arquitetura: [27]

Aplicativo SDN
Os aplicativos SDN são programas que comunicam de forma explícita, direta e
programática seus requisitos de rede e o comportamento de rede desejado ao SDN
Controller por meio de uma interface de direção norte (NBI). Além disso, eles podem
consumir uma visão abstrata da rede para fins internos de tomada de decisão. Um
aplicativo SDN consiste em uma lógica de aplicativo SDN e um ou mais drivers NBI. Os
aplicativos SDN podem expor outra camada de controle de rede abstraído, oferecendo
assim um ou mais NBIs de nível superior por meio dos respectivos agentes NBI.
 Controlador SDN
O SDN Controller é uma entidade logicamente centralizada encarregada de (i) converter
os requisitos da camada SDN Application para os SDN Datapaths e (ii) fornecer aos
SDN Applications uma visão abstrata da rede (que pode incluir estatísticas e
eventos) . Um controlador SDN consiste em um ou mais agentes NBI, a lógica de
controle SDN e o driver CDPI (Control to Data-Plane Interface). A definição como
entidade logicamente centralizada não prescreve nem exclui detalhes de
implementação, como federação de múltiplos controladores, conexão hierárquica de
controladores, interfaces de comunicação entre controladores, nem virtualização ou
divisão de recursos de rede.

Datapath SDN
O SDN Datapath é um dispositivo de rede lógica que expõe visibilidade e controle
incontestado sobre seus recursos anunciados de encaminhamento e processamento de
dados. A representação lógica pode abranger todos ou um subconjunto dos recursos
físicos do substrato. Um SDN Datapath compreende um agente CDPI e um conjunto de
um ou mais mecanismos de encaminhamento de tráfego e zero ou mais funções de
processamento de tráfego. Esses mecanismos e funções podem incluir
encaminhamento simples entre as interfaces externas do caminho de dados ou as
funções internas de processamento ou finalização de tráfego. Um ou mais Datapaths
SDN podem estar contidos em um único elemento de rede (físico) - uma combinação
física integrada de recursos de comunicação, gerenciada como uma unidade. Um
caminho de dados SDN também pode ser definido em vários elementos da rede
física.Camada OSI 4-7 funções.

Controle SDN para interface de plano de dados (CDPI)

O SDPI CDPI é a interface definida entre um SDN Controller e um SDN Datapath, que
fornece pelo menos (i) controle programático de todas as operações de
encaminhamento, (ii) anúncio de recursos, (iii) relatório de estatísticas e (iv) notificação
de eventos. Um valor do SDN reside na expectativa de que o CDPI seja implementado
de maneira aberta, neutra e interoperável pelo fornecedor.

SDN Northbound Interfaces (NBI)

Os NBIs SDN são interfaces entre aplicativos SDN e controladores SDN e geralmente
fornecem visualizações abstratas da rede e permitem a expressão direta do
comportamento e dos requisitos da rede. Isso pode ocorrer em qualquer nível de
abstração (latitude) e em diferentes conjuntos de funcionalidades (longitude). Um valor
do SDN reside na expectativa de que essas interfaces sejam implementadas de maneira
aberta, neutra em relação ao fornecedor e interoperável.

Plano de controle SDN 

Centralizado - Hierárquico - Distribuído
A implementação do plano de controle SDN pode seguir um design centralizado,
hierárquico ou descentralizado. As propostas iniciais do plano de controle SDN focaram
em uma solução centralizada, em que uma única entidade de controle tem uma visão
global da rede. Embora isso simplifique a implementação da lógica de controle, ele tem
limitações de escalabilidade à medida que o tamanho e a dinâmica da rede
aumentam. Para superar essas limitações, várias abordagens foram propostas na
literatura que se enquadram em duas categorias, abordagens hierárquicas e totalmente
distribuídas. Em soluções hierárquicas, [28] [29] controladores distribuídos operam em uma
exibição de rede particionada, enquanto decisões que requerem conhecimento em toda
a rede são tomadas por um controlador raiz logicamente centralizado. Em abordagens
distribuídas, [30][31] controladores operam em sua exibição local ou podem trocar
mensagens de sincronização para aprimorar seus conhecimentos. As soluções
distribuídas são mais adequadas para suportar aplicativos SDN adaptáveis.
Colocação do controlador
Uma questão importante ao projetar um plano de controle SDN distribuído é decidir o
número e o posicionamento das entidades de controle. Um parâmetro importante a
considerar ao fazer isso é o atraso de propagação entre os controladores e os
dispositivos de rede, [32] especialmente no contexto de grandes redes. Outros objetivos
que foram considerados envolvem confiabilidade do caminho de controle, [33] tolerância
a falhas e [34] e requisitos de aplicação. [35]

Encaminhamento SDN fluxo (SDN) 

Proativo vs Reativo vs Híbrido

O OpenFlow usa tabelas TCAM para rotear seqüências de pacotes (fluxos) . Se os

fluxos chegarem a um comutador, uma consulta à tabela de fluxos será
realizada. Dependendo da implementação da tabela de fluxo, isso é feito em uma
tabela de fluxo de software se um vSwitch for usado ou em um ASICse for
implementado em hardware. No caso em que nenhum fluxo correspondente é
encontrado, uma solicitação ao controlador para obter mais instruções é enviada. Isso é
tratado em um dos três modos diferentes. No modo reativo, o controlador age após
essas solicitações e cria e instala uma regra na tabela de fluxo para o pacote
correspondente, se necessário. No modo proativo, o controlador preenche as entradas
da tabela de fluxo para todas as correspondências possíveis de tráfego possíveis para
esse comutador com antecedência. Esse modo pode ser comparado com as entradas
típicas da tabela de roteamento hoje, onde todas as entradas estáticas são instaladas
com antecedência. Após isso, nenhuma solicitação é enviada ao controlador, pois todos
os fluxos de entrada encontrarão uma entrada correspondente. Uma grande vantagem
no modo proativo é que todos os pacotes são encaminhados na taxa de linha
(considerando todas as entradas da tabela de fluxo no TCAM) e nenhum atraso é
adicionado.

Aplicações 

SDMN 
A rede móvel definida por software (SDMN) [38] [39] é uma abordagem para o design de
redes móveis, onde todos os recursos específicos de protocolo são implementados em
software, maximizando o uso de hardware e software genérico e de commodity na rede
principal e na rede principal. rede de acesso via rádio . [40] É proposto como uma
extensão do paradigma SDN para incorporar funcionalidades específicas da rede
móvel . [41] Desde o 3GPP Rel.14, uma arquitetura de controle de separação de usuários
foi introduzida nas arquiteturas da Mobile Core Network com o protocolo PFCP .
SD-WAN [ editar ]
Uma SD-WAN é uma rede de longa distância (WAN) gerenciada usando os princípios de
rede definida por software. [42] O principal fator de SD-WAN é reduzir os custos de WAN
usando linhas alugadas mais acessíveis e disponíveis comercialmente, como uma
substituição alternativa ou parcial de linhas MPLS mais caras . O controle e o
gerenciamento são administrados separadamente do hardware com controladores
centrais, permitindo uma configuração e administração mais fáceis. [43]
SD-LAN 
Uma SD-LAN é uma rede local (LAN) construída em torno dos princípios da rede
definida por software, embora haja diferenças importantes em topologia, segurança de
rede, visibilidade e controle de aplicativos, gerenciamento e qualidade de serviço. [44]
A
 SD-LAN desacopla o gerenciamento de controle e os planos de dados para permitir
uma arquitetura orientada por políticas para LANs com e sem fio. As SD-LANs são
caracterizadas pelo uso de um sistema de gerenciamento em nuvem e conectividade
sem fio, sem a presença de um controlador físico. [45]

Segurança usando o paradigma SDN 

A arquitetura SDN pode ativar, facilitar ou aprimorar aplicativos de segurança
relacionados à rede devido à visão central da rede do controlador e sua capacidade de
reprogramar o plano de dados a qualquer momento. Embora a segurança da
arquitetura SDN em si continue sendo uma questão aberta que já foi estudada algumas
vezes na comunidade de pesquisa, [46] [47] [48] [49], os parágrafos a seguir focam apenas os
aplicativos de segurança possíveis ou revisados usando SDN.
Várias pesquisas sobre SDN já investigaram aplicativos de segurança criados no
controlador SDN, com diferentes objetivos em mente. Detecção e mitigação distribuída
de negação de serviço (DDoS), [50] [51] , bem como botnet [52] e propagação de
worms, [53] são alguns casos de uso concreto de tais aplicações: basicamente, a ideia
consiste em coletar periodicamente redes estatísticas do plano de encaminhamento da
rede de maneira padronizada (por exemplo, usando o Openflow) e, em seguida, aplique
algoritmos de classificação nessas estatísticas para detectar anomalias na rede. Se uma
anomalia for detectada, o aplicativo instrui o controlador como reprogramar o plano de
dados para mitigá-lo.
Outro tipo de aplicativo de segurança utiliza o controlador SDN implementando alguns
algoritmos de MTD (Target Target Defense). Os algoritmos MTD são normalmente
usados para dificultar qualquer ataque a um determinado sistema ou rede, mais do que
o habitual, ocultando ou alterando periodicamente as propriedades principais desse
sistema ou rede. Nas redes tradicionais, a implementação de algoritmos MTD não é
uma tarefa trivial, pois é difícil criar uma autoridade central capaz de determinar - para
cada parte do sistema a ser protegida - quais propriedades principais estão ocultas ou
alteradas. Em uma rede SDN, essas tarefas se tornam mais diretas, graças à
centralidade do controlador. Um aplicativo pode, por exemplo, atribuir IPs virtuais
periodicamente a hosts na rede, e o IP virtual / IP real do mapeamento é executado
pelo controlador. [54]Outro aplicativo pode simular algumas portas abertas / fechadas /
filtradas falsas em hosts aleatórios na rede para adicionar ruído significativo durante a
fase de reconhecimento (por exemplo, varredura) realizada por um invasor. [55]
Um valor adicional referente à segurança em redes habilitadas para SDN também pode
ser obtido usando o FlowVisor [56] e o FlowChecker [57], respectivamente. O primeiro
tenta usar um único plano de encaminhamento de hardware, compartilhando várias
redes lógicas separadas. Seguindo essa abordagem, os mesmos recursos de hardware
podem ser usados para fins de produção e desenvolvimento, além de separar o
monitoramento, a configuração e o tráfego da Internet, onde cada cenário pode ter sua
própria topologia lógica, denominada fatia. Em conjunto com essa abordagem, o
FlowChecker [56] realiza a validação de novas regras do OpenFlow que são implantadas
pelos usuários usando sua própria fatia.
Os aplicativos do controlador SDN são implementados principalmente em cenários de
grande escala, o que requer verificações abrangentes dos possíveis erros de
programação. Um sistema para fazer isso chamado NICE foi descrito em 2012. [58]
A
 introdução de uma arquitetura de segurança abrangente requer uma abordagem
abrangente e prolongada do SDN. Desde que foi introduzido, os designers estão
procurando maneiras possíveis de proteger SDN que não comprometam a
escalabilidade. Uma arquitetura chamada Arquitetura de Segurança SN-SECA (SDN +
NFV). [59]
Entrega de dados de grupo usando SDN 
Os aplicativos distribuídos executados nos datacenters geralmente replicam dados com
o objetivo de sincronização, resiliência de falhas, balanceamento de carga e
aproximação dos dados aos usuários (o que reduz a latência para os usuários e
aumenta a taxa de transferência percebida). Além disso, muitos aplicativos, como o
Hadoop, replicam dados em um datacenter em vários racks para aumentar a tolerância
a falhas e facilitar a recuperação de dados. Todas essas operações requerem a entrega
de dados de uma máquina ou datacenter para várias máquinas ou datacenters. O
processo de entrega confiável de dados de uma máquina para várias máquinas é
conhecido como Entrega de Dados de Grupo Confiável (RGDD).
Os comutadores SDN podem ser usados para o RGDD através da instalação de regras
que permitem o encaminhamento para várias portas de saída. Por exemplo, o
OpenFlow fornece suporte para tabelas de grupo desde a versão 1.1 [60], o que torna isso
possível. Usando o SDN, um controlador central pode configurar cuidadosa e
inteligentemente as árvores de encaminhamento para o RGDD. Essas árvores podem
ser construídas enquanto se presta atenção ao status de congestionamento / carga da
rede para melhorar o desempenho. Por exemplo, o MCTCP [61] é um esquema para
entrega a muitos nós dentro dos datacenters que se baseia em topologias regulares e
estruturadas das redes de datacenter, enquanto o DCCast [62] e o QuickCast [63] são
abordagens para replicação rápida e eficiente de dados e conteúdo nos datacenters.
WANs privadas.

Relação com NFV 

A virtualização de funções de rede NFV é um conceito que complementa o SDN. Assim,
o VNF não depende dos conceitos de SDN ou SDN. O NFV desunida o software do
hardware para permitir a implantação flexível da rede e a operação dinâmica. As
implantações de NFV normalmente usam servidores comuns para executar versões de
software de serviços de rede que anteriormente eram baseadas em hardware. Esses
serviços baseados em software que são executados em um ambiente NFV são
chamados de Funções de rede virtual (VNF). [64] O programa híbrido SDN-NFV foi
fornecido para recursos de alta eficiência, elasticidade e escalabilidade que o NFV
visava acelerar a inovação de serviços e o provisionamento usando tecnologias de
virtualização de TI padrão. [64] [65]O SDN fornece a agilidade de controlar os dispositivos
de encaminhamento genéricos, como roteadores e comutadores, usando controladores
SDN. Por outro lado, a agilidade de NFV é fornecida para os aplicativos de rede usando
servidores virtualizados. É inteiramente possível implementar uma função de rede
virtualizada (VNF) como uma entidade autônoma usando paradigmas de rede e
orquestração existentes. No entanto, existem benefícios inerentes à alavancagem dos
conceitos de SDN para implementar e gerenciar uma infraestrutura de NFV,
principalmente ao analisar o gerenciamento e a orquestração de VNFs, e é por isso que
estão sendo definidas plataformas de múltiplos fornecedores que incorporam SDN e
NFV em ecossistemas concertados. [66]

Relação com DPI 

A inspeção profunda de pacotes do DPI fornece reconhecimento de aplicativo à rede,
enquanto o SDN fornece reconhecimento de aplicativo à rede. [67] Embora o SDN altere
radicalmente as arquiteturas de rede genéricas, ele deve lidar com o trabalho com
arquiteturas de rede tradicionais para oferecer alta interoperabilidade. A nova
arquitetura de rede baseada em SDN deve considerar todos os recursos atualmente
fornecidos em dispositivos ou software separados, exceto os principais dispositivos de
encaminhamento (roteadores e comutadores), como o DPI, dispositivos de
segurança [68]