SDN: plano de controle × dados, OpenFlow, northbound × southbound; NFV

A ideia que organiza o assunto

Na rede tradicional, cada equipamento é autônomo: um roteador roda seus próprios protocolos, calcula suas próprias rotas, mantém suas próprias tabelas e é configurado individualmente, na sua própria linha de comando. Inteligência e encaminhamento moram na mesma caixa, e isso significa que mudar uma política de rede é repetir a mesma configuração em dezenas de caixas, uma a uma.

A SDN desfaz esse casamento. Ela retira do equipamento a parte que decide e a recolhe em um controlador logicamente centralizado, que enxerga a topologia inteira. O equipamento fica com a parte que executa: receber o pacote, consultar a tabela e encaminhar, o mais rápido que puder.

Dessa separação única decorre tudo o que a prova cobra:

Visão global. O controlador conhece a rede toda, e não apenas a vizinhança de um nó; decisões que exigiriam convergência distribuída passam a ser calculadas de uma vez.
Programabilidade. A rede passa a ser configurada por software e por política, não por sessão de terminal em cada dispositivo.
Abertura. Com interface padronizada entre controlador e equipamento, o plano de dados deixa de depender do sistema proprietário do fabricante.

Diante de qualquer item, portanto, pergunte: isso é decidir ou é encaminhar? Decidir é plano de controle, mora no controlador. Encaminhar é plano de dados, mora no comutador. Item que devolva ao equipamento uma decisão de controle — ou que mantenha a configuração manual dispositivo a dispositivo — contradiz a premissa da arquitetura.

Como funciona

Os três planos. O plano de dados (ou de encaminhamento) é o do equipamento: consulta a tabela de fluxos e trata o pacote. O plano de controle é o do controlador: constrói a visão da rede e programa as tabelas de todos os equipamentos. O plano de gerenciamento cuida de monitoração, provisionamento e política, acima dos outros dois.

As duas interfaces. Do controlador para baixo, até os equipamentos, vai a interface southbound, e o protocolo emblemático dela é o OpenFlow, padronizado pela Open Networking Foundation — há outras, como NETCONF, OVSDB e P4Runtime. Do controlador para cima, até as aplicações de rede — engenharia de tráfego, firewall, balanceamento, automação —, vai a interface northbound, tipicamente uma API REST, que não tem um padrão único consagrado. Guardar a geografia resolve o par: o controlador está no meio, south desce ao hardware, north sobe à aplicação.

O OpenFlow e as tabelas de fluxo. O comutador OpenFlow mantém uma ou mais tabelas de fluxo, e cada entrada tem três partes: os campos de correspondência (porta de entrada, endereços MAC e IP, VLAN, portas de transporte), os contadores e as instruções ou ações — encaminhar por determinada porta, descartar, reescrever campo, enviar ao controlador. Chegando um pacote que não casa com nenhuma entrada, o comutador o entrega ao controlador (mensagem packet-in), que decide e instala a regra correspondente para os próximos. O canal entre os dois é uma conexão TCP, normalmente sobre TLS.

Controlador e centralização. ONOS, OpenDaylight, Ryu e Floodlight são os controladores citados em prova. A centralização é lógica, não física: na prática o controlador é implantado em cluster, justamente porque um controlador único seria o ponto de falha e o gargalo de toda a rede.

SDN × NFV. São coisas distintas e complementares. A SDN separa controle de encaminhamento; a NFV (virtualização de funções de rede) tira funções como firewall, balanceador e roteador de equipamentos dedicados e as executa como software em servidores de prateleira. Pode-se ter uma sem a outra.

O que decide os itens

Plano de controle × plano de dados:

	plano de controle	plano de dados
verbo	decidir	encaminhar
onde fica na SDN	controlador, centralizado	comutador, distribuído
o que produz	a tabela de fluxos	o pacote na porta de saída
exemplo tradicional	OSPF, BGP calculando rotas	consulta à FIB e transmissão

Southbound × northbound:

	southbound	northbound
liga	controlador → equipamentos	controlador → aplicações
protocolo típico	OpenFlow, NETCONF, OVSDB, P4Runtime	API REST
padronização	consolidada (ONF)	sem padrão único

SDN × rede tradicional — na tradicional, controle e encaminhamento coexistem em cada caixa e a configuração é por dispositivo; na SDN, o controle sai da caixa e a configuração é centralizada e programável.

SDN × NFV — SDN separa planos; NFV virtualiza funções de rede em servidores comuns. Não são sinônimos.

Centralização lógica × física — logicamente centralizado, fisicamente distribuído em cluster; o controlador redundante é exigência, não detalhe.

Números que caem


OpenFlow — porta oficial	6653/TCP (a legada, muito citada, é 6633)
versões cobradas	1.0 (tabela única) e 1.3 (múltiplas tabelas, grupos)
entrada de fluxo	correspondência + contadores + instruções/ações
planos	3: dados, controle e gerenciamento
quem padroniza o OpenFlow	ONF (Open Networking Foundation)

Como a CEBRASPE derruba você aqui

O tópico tem 1 item, e ele está explicado. Um item não é frequência: não há percentual a citar, nem distorção mais comum, nem estilo de banca a inferir. O primeiro parágrafo abaixo é o que o corpus de fato mostra; os três seguintes são armadilhas conhecidas da arquitetura que este corpus não mediu, e estão aqui porque o assunto é cobrado com peso altíssimo e o candidato precisa delas.

A premissa invertida: a SDN que não muda nada. O único item medido do tópico concede a abstração e nega a consequência — “apesar de a SDN abstrair os recursos de rede para um sistema virtualizado, a gerência de cada dispositivo dessa rede ainda tem de ser feita de forma manual”. É exatamente o oposto do que a arquitetura entrega: eliminar a configuração equipamento a equipamento é a razão de ela existir. Defesa: a estrutura “apesar de X, continua valendo Y” é um molde frequente da banca, em que X é verdadeiro e serve de credencial para um Y que contradiz o objetivo da tecnologia. Leia o Y sozinho e confronte-o com a finalidade.

Os planos trocados de dono — não medido. Espere ver o controlador encarregado de encaminhar pacotes, ou o comutador calculando rotas e decidindo políticas. Defesa: aplique o verbo — decidir é controle, encaminhar é dados.

As interfaces invertidas — não medido. OpenFlow apresentado como interface northbound, ou a API REST das aplicações chamada de southbound. Defesa: a geografia do nome basta — south desce ao equipamento, north sobe à aplicação.

A centralização levada ao pé da letra — não medido. Item que trate o controlador como necessariamente uma única máquina, ou que negue a possibilidade de redundância. Defesa: a centralização é lógica; a implantação real é em cluster.

Erros clássicos

Achar que a SDN elimina o plano de controle. Ela não elimina: desloca. O controle continua existindo, só que fora do equipamento e centralizado.

Trocar southbound por northbound. OpenFlow fala com o hardware (southbound); a API REST fala com as aplicações de rede (northbound).

Tratar SDN e NFV como a mesma coisa. Uma separa controle de encaminhamento; a outra virtualiza funções de rede em servidores comuns.

Supor que centralização lógica significa um servidor só. Controlador único seria gargalo e ponto único de falha; a implantação é em cluster.

Manter a configuração dispositivo a dispositivo. Se o item conserva a gerência manual em cada equipamento, ele está descrevendo a rede tradicional com o nome da SDN.

Confundir tabela de fluxos com tabela de roteamento. A entrada de fluxo casa campos de várias camadas — porta física, MAC, IP, VLAN, portas de transporte — e não apenas o prefixo de destino.