Resumo

  • O rascunho atual de MPLS STAMP depende de mecanismos e parâmetros provisionados localmente nas duas pontas e deixa fora de escopo a sinalização VCCV específica para STAMP.
  • O retorno de um pacote é evidência útil do intercâmbio, mas não registra se as duas pontas compartilhavam toda a definição operacional da medição.

O trecho mais importante de draft-ietf-mpls-stamp-pw-21 para quem governa uma operação não é uma figura de encapsulamento. O texto diz que o mecanismo usado para terminar o pacote STAMP em um LSP ou pseudowire é provisionado localmente nas duas extremidades. Em seguida, exclui do escopo extensões de sinalização VCCV específicas para STAMP em PWs. Para LSPs, onde a sinalização VCCV não foi definida, o provisionamento local é descrito como a única opção disponível hoje.

A revisão 21, publicada em 10 de setembro de 2026, também explicita que o procedimento se destina a um único domínio administrativo. É uma limitação importante. Ainda assim, um domínio pode conter vários controladores, equipes, fornecedores e calendários de mudança. A unidade administrativa não transforma duas escritas locais numa transação única.

O identificador aponta para um estado local

O RFC 8762 define uma sessão STAMP como o fluxo bidirecional entre um emissor e um refletor durante certo período. Configuração e gestão ficam fora do padrão e podem ser realizadas por CLI, OSS/BSS, SNMP ou um controlador NETCONF/YANG. Depois de configurado, o refletor opera de forma stateful ou stateless, com pacotes autenticados ou não autenticados.

O RFC 8972 acrescenta o SSID. Antes do teste, o refletor deve receber todos os elementos necessários para identificar a sessão e descartar pacotes que não correspondam a ela. O meio de provisionamento não é definido. O rascunho MPLS exige SSID diferente de zero nos dois sentidos e adapta a identificação ao transporte.

No Format-1, endereço, porta UDP de destino, SSID e parâmetros locais participam do reconhecimento. No Format-2, que não possui cabeçalho IP/UDP, o SSID é unido ao contexto do LSP ou PW — inclusive ao sentido — e aos parâmetros locais. Assim, o valor no pacote funciona como uma chave. Ele encontra um registro; não substitui o registro.

Duas chaves funcionarem não demonstra que os registros têm o mesmo significado. Uma ponta pode associar a sessão a um serviço contratado e a outra, a uma visão de manutenção do transporte. Elas podem concordar em formato e SSID, mas divergir no modo do refletor, na autenticação, nos TLVs, na origem de tempo, na taxa ou no limiar de alerta. As fontes não dizem que isso ocorreu em determinada rede. Elas mostram por que a resposta, sozinha, não consegue provar o contrário.

VCCV já estabelece um acordo limitado

Não seria correto afirmar que um pseudowire não negocia nada. O RFC 5085 permite anunciar capacidades de Control Channel e Connectivity Verification. Os PEs trocam combinações aceitas, escolhem uma opção em comum e a conservam até nova sinalização do PW. O RFC 7708 introduz o tipo 4 baseado em GAL e sua precedência quando há mais de uma alternativa.

O rascunho MPLS STAMP reaproveita esses mecanismos para retirar o pacote de teste do encaminhamento normal e entregá-lo ao plano de controle. Exatamente um mecanismo de exceção deve operar em cada sessão. Depois vem uma função diferente: o tipo G-ACh identifica se o conteúdo está em Format-1, com IP/UDP, ou Format-2, sem esses cabeçalhos.

A escolha VCCV prova que as pontas encontraram uma capacidade de canal comum. Ela não negocia necessariamente o conjunto integral de parâmetros STAMP: SSID, formato, LSP/PW, endereços e portas, modos de estado e autenticação, TLVs, tamanho, taxa, relógio, serviço e finalidade decisória. O próprio rascunho preserva esses elementos no domínio do estado local.

Portanto, há acordos, mas eles pertencem a objetos diferentes. O problema aparece quando a operação transforma “capacidade VCCV selecionada”, “resposta STAMP recebida” e “serviço correto” numa única afirmação sem origem identificável.

O alcance honesto de uma resposta

Um pacote de retorno bem formado, com o SSID previsto, comprova algo concreto. O emissor enviou; houve um contexto de encaminhamento utilizável; o refletor retirou e identificou o pacote; e o caminho de volta encontrou compatibilidade suficiente. Conforme o modo e a validação, isso pode sustentar cálculos de atraso, variação ou perda.

O pacote não nomeia quem aprovou as configurações nem suas gerações. Não comprova que as pontas ligaram a sessão ao mesmo serviço, objetivo de diagnóstico ou obrigação. Também não demonstra que os relógios estavam dentro da mesma margem, que a taxa do teste foi autorizada, que havia folga de MTU ou que uma mudança unilateral posterior não tornou o vínculo obsoleto.

Essa limitação não torna a métrica inútil. Ela obriga a rotulá-la corretamente. A troca de pacotes é evidência da troca; a coerência de configuração, a qualidade temporal e a relação com o serviço exigem evidências próprias.

Um recibo bilateral da medição

O complemento pode ser pequeno e local. Um recibo bilateral de configuração de medição começa pelas identidades do emissor e refletor, domínio administrativo, LSP ou PW e direção, mecanismo de exceção, formato STAMP, tipo G-ACh e SSID. Para Format-1, inclui endereços e portas. Para Format-2, inclui os contextos de ida e volta usados na identificação.

O recibo registra então a semântica: refletor stateful ou stateless, modo autenticado ou não, TLVs, origem do relógio e evidência de sincronização, tamanho e margem de MTU, taxa, capacidade de retorno prevista, serviço associado, objetivo de observação e tipo de decisão que pode usar o resultado. Esses dados não precisam viajar em cada pacote; precisam compartilhar uma identidade.

Cada lado contribui com um hash ou referência imutável da geração de configuração. O registro nomeia o controlador ou operador de origem, o revisor que aceitou o par, os testes de compatibilidade, a validade e a autoridade de reversão. Uma alteração em qualquer ponta cria um novo recibo. O SSID continuar respondendo não permite herdar silenciosamente a aprovação antiga.

Os níveis de evidência também permanecem separados: capacidade VCCV em comum, parâmetros STAMP compatíveis, resposta recebida, relógios em política, métrica calculada e objetivo de serviço atendido. Um sistema posterior só deve usar o nível realmente comprovado.

Esse recibo é uma proposta editorial de Daniel Kade, não um novo campo, registro ou requisito do IETF. Ele mantém as informações organizacionais fora do protocolo, mas dentro da cadeia de responsabilidade.

A compatibilidade parcial engana melhor

Uma incompatibilidade total costuma produzir descarte e chamar atenção. A compatibilidade parcial pode conservar uma série limpa enquanto muda seu significado.

Um refletor alterado de stateful para stateless ainda responde, mas muda a inferência de perda. Uma troca de modo de autenticação altera a confiança permitida. Um novo vínculo de caminho pode manter o SSID e deixar antigo o nome do serviço no painel. Um relógio em holdover pode gerar horários ordenados cuja incerteza já excede o uso aprovado.

São cenários de governança, não relatos de incidentes. O pacote de fontes não contém falha de fornecedor, adoção universal ou caso operacional. O ponto verificável é lógico: sucesso no fio não é o hash da configuração completa.

Fontes

  1. Rascunho MPLS STAMP, histórico e registro da API
  2. Revisão 21 em HTML, texto, XML e diferenças 20–21
  3. Registro de votação do IESG, write-up do shepherd e grupo MPLS
  4. RFC 8762 e RFC 8972
  5. RFC 5085, RFC 7708 e RFC 5586
  6. RFC 7799, Minimum Initial Specification e The Policy Mirror