Resumo

  • O objeto MPLS do ICMP usa uma classe e um subtipo comuns para relatar uma pilha cujos rótulos têm significado local.
  • A informação registrada é a pilha na chegada ao roteador que emite o erro, preservada ao lado da citação IP original.
  • Nem o formato nem o registro obrigam todos os equipamentos a revelar dados, responder a sondas ou tornar o caminho inteiro observável.

Dois tipos de número na mesma mensagem

Classe 1, subtipo 1. Essa combinação informa ao programa que ele está diante de um objeto contendo a pilha MPLS de entrada. Os valores de rótulo encontrados dentro dele pertencem a outra categoria de significado.

A distinção parece burocrática até alguém tentar transformar uma saída de traceroute em mapa. Se dois roteadores mostram o mesmo valor, seria tentador unir os dois pontos como partes de um mesmo objeto persistente. O número, sozinho, não autoriza essa conclusão.

A RFC 3031, de janeiro de 2001, define o rótulo MPLS como identificador de significado local para uma classe de equivalência de encaminhamento. Ele não é uma codificação do endereço IP de destino. Seu sentido depende da associação e do espaço de rótulos aplicáveis naquele contexto.

Já a combinação de classe e subtipo, registrada para o objeto descrito na RFC 4950, de agosto de 2007, permite que implementações diferentes concordem sobre como ler o relatório. O registro organiza a descrição. Não distribui os rótulos locais descritos.

Essa diferença estabelece a escala real do avanço: tornar uma evidência compreensível entre redes sem fingir que ela adquiriu uma identidade universal.

O pacote aparecia, a decisão ficava de fora

O motivo para criar esse objeto estava numa etapa anterior à mensagem de erro.

Quando um roteador de comutação de rótulos recebe um datagrama encapsulado em MPLS que não pode entregar, ele remove a pilha inteira e expõe o datagrama IP. O processamento de erro pode então produzir uma mensagem ICMP com a causa da falha, o cabeçalho IP e o começo da carga original.

A citação pode estar correta. Ainda assim, não inclui a pilha que chegou com o pacote. Aquela era precisamente a informação que o roteador consultaria para encaminhá-lo.

A RFC 4950 recomenda que mensagens selecionadas tragam a pilha recebida e exige que mantenham o cabeçalho IP e os primeiros bytes da carga original. Não se trata de trocar uma prova por outra. A citação IP ajuda a relacionar o erro à comunicação; a pilha acrescenta o contexto de encaminhamento no ponto que relata a falha.

O relatório deixa de perder automaticamente uma parte importante da cena. Mas continua sendo um relato delimitado, não uma reprodução de todas as decisões tomadas pela rede.

Por que citar mais IP não bastava

Na RFC 792, publicada em setembro de 1981, a mensagem Time Exceeded incluía o cabeçalho IP e os primeiros 64 bits dos dados do datagrama original. Esses oito bytes ajudavam o host a associar a resposta ao processo correto, inclusive por números de porta quando utilizados pelo protocolo superior.

O objetivo era reconhecer a comunicação afetada. Não era registrar toda camada de estado usada ao longo do caminho. Também seria incorreto transformar esse formato histórico numa afirmação de que todas as mensagens ICMP posteriores sempre citariam apenas oito bytes de dados.

O problema do MPLS não se resolvia simplesmente prolongando essa citação. Conforme a RFC 3032, a pilha fica entre os cabeçalhos de enlace e o cabeçalho da camada de rede. Ela estava antes do IP e já havia sido retirada.

Cada entrada ocupa quatro octetos. A do topo aparece primeiro; a última é marcada pelo bit S. A consulta ao rótulo superior determina, entre outras coisas, o próximo salto e a operação sobre a pilha: substituir, retirar ou acrescentar entradas conforme o caso.

Uma citação maior do conteúdo interno não recupera necessariamente o estado externo que orientava esse processamento. Para preservá-lo, era preciso nomeá-lo e transportá-lo separadamente.

O instante faz parte do significado

Um único objeto da RFC 4950 representa a pilha completa, na ordem e no formato em que chegou ao roteador emissor do erro. Ele pode ser anexado a Time Exceeded e Destination Unreachable, em ICMPv4 ou ICMPv6. Isso não equivale a permitir o objeto em qualquer tipo de ICMP.

A palavra entrada impede várias leituras apressadas. A pilha relatada não é a que sairia do equipamento depois de uma operação bem-sucedida. Tampouco é uma consulta à configuração atual do roteador. É o estado recebido por aquele equipamento para aquele pacote.

O comprimento do objeto inclui quatro octetos de cabeçalho e mais quatro por entrada. Uma pilha de três entradas, por exemplo, forma um objeto de dezesseis octetos. É uma conta ilustrativa, não um resultado medido. O cabeçalho geral de extensão que o antecede não está incluído nessa conta.

Cada entrada contém vinte bits para o rótulo, três bits chamados EXP no texto de 2007, um bit S e oito de TTL. Em fevereiro de 2009, a RFC 5462 adotou o nome Traffic Class, TC, esclarecendo o uso dos antigos bits EXP. A mudança não aumentou o tamanho da entrada.

Uma interface histórica pode conservar a legenda EXP. Isso não torna aqueles bits um espaço de experimentação irrestrita no presente. O leitor precisa distinguir a terminologia da época da semântica posteriormente esclarecida.

O relatório precisava de divisórias

O objeto MPLS depende da RFC 4884, de abril de 2007. Ela define uma estrutura de extensão para certas mensagens ICMP: depois da região que cita o datagrama original, vêm um cabeçalho de extensão e um ou mais objetos.

Sem uma fronteira explícita, bytes de evidência poderiam ser confundidos com bytes do pacote citado. A solução foi usar um atributo de comprimento de oito bits, ocupando espaço antes reservado. No ICMPv4, a unidade é uma palavra de 32 bits; no ICMPv6, uma de 64 bits.

Quando existe extensão, a região citada deve ter pelo menos 128 octetos. Um original menor exige preenchimento com zeros, além do alinhamento correspondente. Esse número é um mínimo do novo formato, não o máximo universal da citação.

A história tornou o mínimo mais complicado. A RFC 4884 relata implementações produzidas entre 1999 e sua publicação que já anexavam extensões depois de exatamente 128 octetos, mas não preenchiam o novo comprimento. Alguns leitores aprenderam a procurar a extensão naquela posição fixa.

Um remetente que desejasse manter compatibilidade com esses leitores deveria continuar usando exatamente 128 octetos. Se enviasse mais, um leitor moderno poderia seguir o comprimento informado; o antigo poderia procurar o cabeçalho no lugar errado.

A rede não mudou necessariamente. Mudou a relação entre a mensagem e a hipótese que um programa fazia sobre ela.

O modo antigo não era o padrão novo

Para uma aplicação conforme à RFC 4884, comprimento zero significa ausência de extensões. A regra é clara, mas deixa de reconhecer mensagens antigas que continham uma extensão sem anunciá-la dessa maneira.

Por isso, o documento exige que implementações conformes de traceroute ofereçam um modo não padrão para interpretar essas respostas. Nesse modo, uma mensagem longa o bastante pode ser examinada na posição fixa antiga, verificando versão e soma de verificação do cabeçalho.

A acomodação é explícita. O comportamento histórico não precisa ser introduzido silenciosamente em toda leitura. Quem interpreta o resultado deve saber se a ferramenta seguiu uma fronteira declarada ou a hipótese de compatibilidade.

Aplicações clássicas, sem conhecimento de extensões, podem tratar os novos bytes como continuação da citação original. A RFC examina impactos conhecidos dessa situação; não promete que toda aplicação antiga será indiferente à mudança.

O cabeçalho de extensão usa a versão 2. A presença de um objeto desconhecido não torna, por si só, a mensagem inteira malformada. Mas comprimentos e sintaxe precisam ser conferidos. Uma soma de verificação não é uma assinatura digital e não autentica automaticamente o roteador que parece responder.

A estrutura oferece uma maneira comum de expressar uma afirmação. A confiança na origem dessa afirmação é outro problema.

A pilha que transporta o erro é outra coisa

Há um segundo uso de MPLS no processamento de erros, já discutido pela RFC 3032. Um roteador interno ao domínio pode não conhecer a rota de volta à origem IP.

Em determinados cenários, o documento descreve encapsular o ICMP gerado e encaminhá-lo primeiro na direção do destino do pacote original. A mensagem alcança um roteador que sabe enviá-la à origem. Os valores dos rótulos podem ser copiados, mas os TTLs são ajustados para a viagem do novo pacote.

Essa pilha externa está trabalhando no encaminhamento do erro. O objeto da RFC 4950 está dentro do erro, descrevendo o estado de chegada de outro pacote.

Confundir os dois transforma um registro em mecanismo e um mecanismo em registro. Também pode distorcer a interpretação do tempo de ida e volta: o retorno do ICMP pode fazer um desvio, enquanto a pilha citada se refere à entrada do pacote original. O número mostrado pelo traceroute não revela sozinho quanto tempo pertence a cada trecho.

Mais informação não obriga a rede a responder

A RFC 4950 ressalta que não redefine toda a relação entre MPLS e ICMP nem as regras de TTL de cada encapsulamento. Se essas regras impedem o funcionamento básico do traceroute, impedem também sua versão enriquecida.

A RFC 3443, de janeiro de 2003, explica modelos relevantes. No Uniform, os TTLs interno e externo são sincronizados nas bordas do túnel. Nos modelos Pipe, o valor externo inicial pode ser independente do interno.

Assim, variar o TTL do pacote IP interno não garante produzir um erro em cada salto do caminho MPLS como o observador espera. Isso não significa que o TTL externo seja ilimitado, nem que todo ICMP esteja proibido. Significa que a condição que gera a resposta continua importando.

A divulgação também é uma decisão separada. O operador pode selecionar a inclusão da pilha conforme o endereço de destino do erro, uma configuração global ou a profundidade da pilha recebida. A própria RFC 4950 cita a possibilidade de restringir informações a blocos de endereços de administração.

Se nada aparece na tela, a explicação pode estar na geração, na entrega, na política de divulgação ou no leitor. A ausência da informação não basta para concluir que a rede não utiliza MPLS.

O documento dizia, em 2007, que o mecanismo já estava amplamente implantado. Essa é uma afirmação histórica do texto, não uma pesquisa atual de participação nem evidência de adoção simultânea na data da publicação.

O formato comum tornou portátil uma observação local. Seu valor está justamente nessa precisão: preservar algo que antes podia desaparecer, sem prometer que um único relatório mostraria tudo.