Resumo

  • A RFC 3034 chamou de segmento sem TTL uma sequência de LSRs Frame Relay que trocava DLCIs sem reduzir o TTL MPLS; uma fronteira precisava contabilizar de uma vez os saltos omitidos no núcleo.
  • O Hop Count distribuído pelo LDP podia alimentar a subtração na entrada unicast, mas continuava sendo uma declaração do plano de controle, não telemetria do pacote nem comprovante de entrega.

A limitação aparecia entre duas operações que pareciam inseparáveis em um roteador. O equipamento recebia uma trama, consultava o DLCI, escrevia o DLCI de saída e encaminhava. Essa parte funcionava. O circuito de comutação, porém, normalmente não sabia subtrair um do TTL MPLS. Usar o equipamento como Label Switching Router tornava a lacuna relevante para todo o caminho.

Publicada em janeiro de 2001 como Proposed Standard, a RFC 3034 não inventou uma capacidade ausente. Ela isolou uma cadeia desses equipamentos como “segmento sem TTL” e transferiu a contabilidade dos saltos para uma fronteira que pudesse executá-la.

O rótulo operacional ocupava o DLCI

No enlace Frame Relay, o valor do rótulo MPLS atual ficava no campo DLCI do cabeçalho. Rótulos adicionais e os outros campos da pilha permaneciam na encapsulação MPLS genérica. No núcleo, o FR-LSR pesquisava o DLCI de entrada, substituía pelo de saída e enviava a trama.

Era uma representação dividida do mesmo estado lógico. O valor usado pela comutação estava no cabeçalho de enlace; TTL e demais campos significativos da entrada superior continuavam na pilha. Ao atravessar uma fronteira de encapsulação, um LSR precisava decodificar a pilha, aplicar a operação e recodificá-la para o próximo enlace. Dois trechos do mesmo LSP podiam, portanto, exibir formatos diferentes.

Se a saída removesse o último rótulo, a pilha não trazia um identificador explícito do protocolo de rede seguinte. A associação do rótulo precisava permitir essa inferência. Ela governava interpretação e encaminhamento em um domínio limitado; não autenticava o emissor, não autorizava a rota e não comprovava que a trama havia percorrido o circuito esperado.

Saltos invisíveis ao contador ainda consumiam alcance

O TTL do MPLS servia para conter laços e limitar o alcance do pacote. Se cinco comutadores Frame Relay valessem sempre zero, um pacote sairia com mais vida do que teria após cinco roteadores equivalentes. Cada troca local poderia estar correta e, mesmo assim, a propriedade de ponta a ponta estaria errada.

A RFC resumiu a conta como TTL de saída = TTL de entrada - d. O valor de d dependia das encapsulações de entrada, encaminhamento e saída. Uma troca Frame Relay no mesmo nível usava zero no núcleo porque a cobrança estava deslocada. O encaminhamento MPLS genérico normalmente usava um. A entrada em um segmento Frame Relay sem TTL podia usar todo o número de saltos propagado.

No unicast, o comprimento significativo seguia até a entrada, que o subtraía antes de admitir o pacote. No multicast, ele era propagado até a saída, onde a cobrança de fronteira era feita. Mudava o ponto da operação, não o compromisso de fazer os saltos aparecerem no orçamento de TTL.

A entrada decidia antes que o TTL expirasse no escuro

O pagamento antecipado permitia recusar um pacote antes da primeira troca de DLCI. Se a subtração indicasse que o TTL unicast expiraria antes da saída do segmento, a entrada não podia encaminhá-lo com rótulo para dentro daquela região.

Em vez disso, deveria tentar devolver o erro ICMP previsto pelas regras da pilha ou encaminhar o pacote sem rótulo, com o TTL correspondente ao processamento IP. Quando o TTL de entrada fosse um, restava apenas o caminho de erro.

Tentar não é entregar. Um ICMP gerado não prova que a origem o recebeu, e um pacote repassado sem rótulo não prova chegada ao destino. A evidência da entrada se limita à decisão tomada e aos valores usados nela.

Hop Count era estado distribuído, não observação do trajeto

O LDP podia anexar um objeto Hop Count à associação de rótulo. Um FR-LSR que recebesse um valor conhecido do downstream adicionava um antes de anunciá-lo ao upstream. Desconhecido permanecia desconhecido. Se o incremento excedesse o máximo, a associação não podia ser propagada e um erro precisava ser enviado.

No controle ordenado, o nó aguardava um mapeamento do downstream para responder ao upstream e podia incluir a contagem incrementada. No controle independente, podia anunciar primeiro um mapeamento com contagem desconhecida e corrigi-la depois. Se o LDP não fornecesse contagem ou a marcasse como desconhecida, o cálculo da RFC 3034 adotava um como padrão.

Esse padrão não media um caminho de um salto. Ele apenas definia o comportamento na ausência de informação. Mesmo uma contagem conhecida era produzida por roteamento e mensagens de distribuição, não pela observação de um pacote. Não demonstrava que todos os comutadores estavam ativos, que o próximo pacote seguiria a mesma sequência ou que chegaria à saída.

Uma mudança de rota exigia uma nova aritmética

O valor podia mudar depois que o upstream já tivesse recebido um mapeamento. O fim de uma descoberta no downstream ou a seleção de outro próximo salto poderia alterar a contagem. O FR-LSR precisava incrementar e propagar a atualização rumo à entrada. Se a nova contagem passasse do máximo, os rótulos da FEC tinham de ser retirados dos vizinhos upstream para que a detecção de laços não dependesse de um número impossível.

Falhas também removiam autoridade. Se um pedido downstream não pudesse ser atendido, um mapeamento provisório criado para um pedido upstream deveria ser destruído e retirado. A perda da sessão LDP exigia descartar as associações aprendidas por aquela conexão. Até a retenção liberal só permitia reuso quando rota e Hop Count satisfizessem as condições do documento.

Logo, uma linha presente na base de rótulos não bastava para comprovar um caminho operacional. Era preciso conhecer sua sessão de origem, a dependência downstream, a rota vigente e se a contagem atualizada realmente alcançara a entrada.

Adaptar-se ao hardware não juntou as camadas de realidade

Um comutador Frame Relay usado como LSR tinha de alocar e manter rótulos e participar como par no roteamento da camada de rede. Ao mesmo tempo, o controle Frame Relay tradicional e o controle por rótulos podiam coexistir de forma independente no mesmo equipamento e nas mesmas interfaces, compartilhando apenas recursos limitados, como a divisão do espaço de DLCI. A operação combinada ficou fora do escopo.

O compromisso era preciso: a rota escolhia uma dependência, o LDP declarava um comprimento, a entrada fazia uma subtração e o núcleo trocava DLCIs. O pacote observado e o TTL de saída eram recibos diferentes. A RFC 3034 moveu trabalho para respeitar uma limitação do silício; não moveu a verdade do percurso para dentro do número de controle.

Fontes

Lu Heng não escreveu nem endossou a RFC 3034 ou os padrões relacionados. Seus ensaios são usados aqui como lentes analíticas explicitamente declaradas.