Resumo

  • Sem uma barreira, o OpenFlow permite reordenar mensagens por desempenho. Na mesma conexão, a Barrier Reply informa que as mensagens anteriores foram totalmente processadas, com respostas ou erros, antes do início das posteriores.
  • A própria especificação separa processamento de entrega: até um Packet-Out totalmente processado pode não sair do switch por congestionamento, QoS, porta bloqueada ou inválida.
  • A contribuição de Nick McKeown é compartilhada com os demais autores originais e com a comunidade que amadureceu o protocolo. Respeitar essa arquitetura significa manter recibos distintos para intenção, canal, ordem, estado, match, egresso, caminho e resultado.

O pacote que ficou fora do relato

O controlador envia um FlowMod, em seguida uma Barrier Request, e recebe a resposta. A sequência parece completa. Mas a regra pode estar na tabela errada, ter uma máscara incorreta ou perder para uma entrada de prioridade maior. Um group pode escolher outro bucket. Um meter pode descartar. A porta pode estar bloqueada. O enlace seguinte pode estar rompido. Todas essas condições convivem com uma Barrier Reply legítima.

A versão 1.3.5 do OpenFlow define o mecanismo para ordenar dependências em uma conexão. Na ausência de barreira, o switch pode reordenar mensagens para melhorar desempenho. Tudo o que vem antes da Barrier Request precisa ser processado por completo, inclusive com respostas e erros gerados; depois a barreira é processada e respondida; só então começam as mensagens seguintes.

Os exemplos são concretos: criar um group antes de instalar o flow que o referencia; modificar uma porta antes de usá-la em um Packet-Out; adicionar um flow antes de mandar um pacote atravessar a tabela. A resposta certifica a fronteira temporal. Não certifica um trajeto de dados.

O valor de uma interface com limites claros

O artigo de 2008 foi assinado por Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker e Jonathan Turner. A proposta permitia que um controlador acrescentasse e removesse entradas nas tabelas de switches reais, mantendo os pacotes seguintes no encaminhamento rápido. No exemplo Amy-OSPF, o programa escolhe o caminho e configura cada equipamento.

McKeown é um dos originadores do OpenFlow e de SDN, não o inventor único. A semântica posterior de Barrier também não pertence a uma pessoa: especificações e práticas receberam contribuições de muitos participantes e da Open Networking Foundation. A relevância dele aqui está na arquitetura que deixou visível o ponto entre decisão e execução. Quando a fronteira é explícita, uma organização pode atribuir significado exato a cada comprovante.

O histórico de implantações de 2014 relata que o aprendizado em campo levou à introdução de Barrier no OpenFlow 0.9. O documento também registra latências variáveis na instalação de flows, CPUs frágeis em switches, problemas de controle in-band e investigação que combinava traços do canal, RTT, CPU, taxa de configuração e medições da aplicação. Barrier resolveu uma parte da ordem; não apagou as outras camadas.

O significado de “totalmente processado”

O limite mais importante vem do próprio padrão 1.3.5: processar completamente um Packet-Out não garante que ele saia do switch. Congestionamento, QoS, porta bloqueada ou inválida podem causar descarte silencioso depois do processamento OpenFlow. Pacotes destinados ao controlador também podem desaparecer sob policiamento ou congestionamento sem o Packet-In esperado.

Um flow entry contém match, prioridade, contadores, instruções, timeouts e cookie. O pipeline começa na tabela 0 e pode prosseguir por outras. A entrada correspondente de maior prioridade vence em cada tabela; instruções alteram metadados ou action sets e acionam groups, meters e egresso. Assim, ler o cookie correto depois da barreira comprova estado, mas não match. Um delta de contador comprova match local, mas não o enlace seguinte. Um contador de porta ainda não comprova a aplicação.

O escopo de conexão é igualmente restrito. A especificação não sincroniza conexões diferentes. Se o trabalho dependente viajou por uma conexão auxiliar e a barreira pela principal, a resposta principal não cobre ambos. Depois de um reconnect, é necessário verificar função do controlador, geração do canal e estado efetivamente preservado pelo switch.

A suíte de testes não confunde as perguntas

Na especificação de conformidade Basic Single Table para OpenFlow 1.3.4, o teste de barreira adiciona até 10 mil flows, remove-os e envia uma Barrier Request por uma única conexão de controle. A resposta deve aparecer depois de todas as notificações Flow-Removed solicitadas. Um teste Packet-Out próximo usa separadamente uma conexão de dados e verifica a recepção do pacote.

São testes diferentes porque ordem de comando e recepção de dados são fatos diferentes. Uma automação não deveria fundi-los num único booleano.

Bundles do OpenFlow 1.5.1 tornam a aplicação de configuração mais atômica. Mudanças podem ser preparadas e confirmadas juntas; se uma falhar no commit, o conjunto não deve ser aplicado. O suporte é opcional e limitado pelas capacidades do dispositivo. Mesmo um commit correto revela o estado aplicado, não qual cabeçalho de produção ganhou o pipeline nem se um serviço remoto respondeu.

VeriFlow verifica invariantes de rede à medida que regras mudam, em vez de confiar apenas em código complexo do controlador. Ele pode detectar no modelo um loop, black hole ou violação de política. Ainda assim, o modelo não observa a transmissão física nem a resposta da aplicação. É uma camada adicional de evidência, não o ponto final.

A cadeia mínima de recibos

Uma implantação auditável registra:

  1. Intenção: política versionada e conjunto desejado.
  2. Transporte: Datapath ID, papel e conexão corretos.
  3. Ordem: Barrier Reply nessa conexão, com erros anteriores conciliados.
  4. Estado: leitura posterior de tabela, prioridade, máscara, cookie, group, meter e porta.
  5. Match: pacote controlado e representativo altera os contadores esperados.
  6. Egresso: porta ou fila mostra saída sem condição local de descarte.
  7. Caminho: observação a jusante ou sonda ativa confirma o percurso.
  8. Resultado: endpoint ou aplicação registra a transação.

Os recibos precisam compartilhar versão da mudança, identidade do switch, geração da conexão, transação OpenFlow, cookie, cabeçalho da sonda e janela de tempo. Sem essas chaves, uma leitura antiga pode ser ligada a uma sonda nova e produzir uma conclusão que nunca foi verdadeira.

Fontes