2.1. Pipelines de Processamento: De Função Fixa a Programável

O processo pelo qual um pacote de dados é tratado ao entrar em um switch de rede é melhor descrito como um pipeline. Este pipeline consiste em uma sequência de estágios de processamento pelos quais o pacote deve passar. Cada estágio é responsável por uma tarefa específica, como analisar um cabeçalho, consultar uma tabela de regras ou executar uma ação (por exemplo, modificar ou encaminhar o pacote). A distinção fundamental entre a arquitetura de redes tradicional e o novo paradigma de programabilidade reside na natureza desse pipeline.

2.1.1. O Pipeline de Função Fixa

Em switches de rede tradicionais, e naqueles visados pelas primeiras especificações do OpenFlow, o pipeline é de função fixa. Isso significa que a lógica de processamento e a sequência de estágios são permanentemente gravadas no hardware do switch, geralmente em um Circuito Integrado de Aplicação Específica (ASIC).

Este hardware é projetado para processar um conjunto predefinido de protocolos em uma ordem estrita e imutável. Por exemplo, um pipeline fixo pode ser estruturado para analisar pacotes assumindo sempre a sequência Ethernet→VLAN→IPv4→TCP. Conforme discutido na Seção 1.3, o OpenFlow opera sobre este modelo, permitindo que um controlador SDN gerencie as regras (entradas nas tabelas de fluxo) dentro desses estágios fixos. Contudo, o controlador não pode alterar os estágios em si, a ordem deles, ou adicionar suporte a protocolos que o ASIC não foi projetado para entender [1].

2.1.2. A Emergência do Pipeline Programável

Em contraposição ao modelo fixo, surge o conceito de pipeline programável. Neste modelo, a estrutura do pipeline não é fixa no hardware. Em vez disso, ela é definida por software, redefinindo fundamentalmente a capacidade do plano de dados.

Esta abordagem concede ao desenvolvedor da rede controle total sobre o comportamento do switch, especificando programaticamente três componentes-chave:

1. O parser (analisador), que define quais cabeçalhos de protocolo o switch deve procurar e como extraí-los.
2. A sequência de estágios de processamento e as tabelas que eles contêm, definindo a lógica de processamento.
3. O conjunto de ações que podem ser executadas sobre os pacotes.

Dessa forma, os operadores de rede podem definir e reconfigurar o comportamento de processamento de pacotes do switch em campo, adaptando-o a novos protocolos ou necessidades específicas da aplicação sem exigir a substituição do hardware.

2.2. O Paradigma "Match-Action": O Motor do Processamento

O "motor" que opera dentro de cada estágio de um pipeline de processamento é o paradigma Match-Action (Combinar-Agir). Popularizado pelo modelo SDN clássico e pelo OpenFlow, ele descreve a operação fundamental do plano de dados.

Cada tabela de regras dentro de um estágio do pipeline é composta por entradas com duas partes principais:

• Match (Combinar): Um conjunto de campos de cabeçalho (ex: endereço MAC, endereço IP, porta TCP) que são usados para comparar com os pacotes recebidos.
• Action (Agir): Um conjunto de instruções (ex: encaminhar para uma porta, descartar, modificar um campo, encapsular) que o switch executa se um pacote corresponder à regra.

No modelo SDN, o plano de controle (o controlador) é responsável por popular essas tabelas de match-action nos switches. Em um pipeline de função fixa, os campos que podem ser usados no Match e as Ações disponíveis são predefinidos pelo hardware. Em um pipeline programável, tanto os campos de Match quanto as Ações são definidos pelo software.

2.3. PISA: Um Modelo Abstrato para o Plano de Dados Programável

Historicamente, os chips para processamento de pacotes implementam um vasto conjunto de funcionalidades fixas, e os sistemas de rede são construídos com base nessas capacidades. Trata-se de um design "bottom-up": o hardware dita o que o software pode fazer. Para adicionar uma nova funcionalidade de processamento de pacotes (como um novo protocolo de encapsulamento), é necessário que o hardware seja substituído, um ciclo de inovação que pode levar anos [5].

Para reverter essa relação, foi proposto um design "top-down", onde o software é quem deve direcionar o hardware. A arquitetura PISA (Protocol-Independent Switch Architecture) surge como o modelo conceitual que formaliza um plano de dados programável capaz de suportar esse design top-down.

O modelo PISA é "independente de protocolo" e define um pipeline lógico genérico composto por três seções principais:

1. Parser Programável: Converte o fluxo de bytes de um pacote em um conjunto de cabeçalhos e metadados legíveis para os estágios seguintes. Sua lógica é definida por software, permitindo que reconheça qualquer protocolo.
2. Pipeline de Tabelas Match-Action (MAT): Uma sequência de estágios, onde cada estágio contém tabelas Match-Action que processam os cabeçalhos e metadados extraídos pelo parser. A sequência de estágios e as regras/ações das tabelas são programáveis.
3. Deparser Programável: Reconstrói o pacote (possivelmente modificado) a partir dos cabeçalhos e metadados processados, convertendo-o de volta a um fluxo de bytes para transmissão.

Durante esse processo, uma estrutura de dados de metadados é utilizada para carregar informações contextuais sobre o pacote entre os estágios do pipeline. Esses metadados podem ser definidos pelo desenvolvedor (carregando informações de estado) ou podem ser metadados intrínsecos à própria arquitetura (ex: ingress_port, packet_length).