Resumo

  • A RFC 2215 separou o valor local de cada elemento do valor composto no caminho e tratou a caracterização como ligada ao próximo salto.
  • Quebra usava OR; saltos conscientes incrementavam; banda e MTU usavam mínimo; latência mínima usava soma limitada.
  • O resultado era uma caracterização condicionada, não reserva, admissão, medição de desempenho, entrega ou sucesso da aplicação.

Um caminho não exigia uma única conta

Um roteador podia receber quatro fatos: houve algum ponto sem o serviço relevante? Quantos elementos entendiam Integrated Services? Qual era a menor banda anunciada? Quanta latência mínima havia sido acumulada?

A RFC 2215 não os reduziu a uma média. Uma quebra basta e pede OR. Um participante acrescenta um. Um gargalo só mantém ou reduz o valor. Um atraso local precisa ser somado. A regra de composição fazia parte do significado da afirmação.

Esses parâmetros descreviam o ambiente QoS para orientar uma possível solicitação. Não registravam que recursos já tinham sido reservados ou que pacotes haviam recebido o serviço.

Fato local e afirmação de caminho

O valor local descrevia um elemento. O composto juntava o trecho anterior à contribuição atual e seguia adiante. A composição podia avançar ao receptor ou voltar ao emissor.

Os parâmetros eram conceitualmente per-next-hop. Em uma mídia compartilhada ou nuvem, saídas diferentes podiam exigir valores diferentes. Tratar o número como propriedade permanente do equipamento apagaria a escolha de rota. IDs distintos permitiam inspecionar tanto o aporte local quanto a afirmação composta.

O número final não recompunha suas origens: o mínimo não localizava o gargalo; a soma não mostrava as parcelas; o OR não apontava a quebra.

Default e override continuavam separados

O service number 1 identificava a ramificação global. Um serviço específico podia fornecer override. Uma ramificação específica usava o override local quando presente e, na falta dele, o global local, sem perder sua identidade. Uma ramificação global que encontrasse override gerava outra ramificação, mantendo a global.

Assim, o encaminhamento comum podia ter MTU 1.500, enquanto Guaranteed Service ficava limitado a 250. O valor menor definia a superfície daquele serviço, não uma nova física do equipamento.

A quebra permanecia verdadeira

NON_IS_HOP indicava ausência do serviço ou uma interrupção conhecida. O OR tornava a afirmação monotônica. Roteadores capazes depois de um túnel desconhecido não podiam corrigir retroativamente o interior do túnel.

O cálculo era conservador. Como o dispositivo incompatível não entendia o próprio marcador, a detecção podia caber a um vizinho, ao protocolo ou à configuração. O break bit não era uma confissão autenticada.

Uma quebra global tornava os outros parâmetros possivelmente imprecisos; uma quebra de serviço enfraquecia os dados desse serviço. A RFC 2210 cuidava do transporte em ADSPEC, não da cura da incerteza.

A contagem registrava participantes conhecidos

NUMBER_OF_IS_HOPS aumentava em cada elemento consciente. Contava contribuintes conhecidos, não necessariamente todos os segmentos. Um elemento alheio não podia contar a si mesmo.

Por isso contagem e break bit deviam ser lidos juntos. Cinco saltos registrados não provavam que o caminho tivesse apenas cinco saltos. Ausência de registro não era ausência do objeto.

Banda era o mínimo de estimativas anteriores à solicitação

Cada elemento estimava disponibilidade física, administrativa e política; a composição retinha o mínimo. Mas a estimativa surgia antes de uma solicitação QoS concreta. Destino, serviço e política de reserva podiam ser desconhecidos. A RFC aceitava até superestimação relevante quando não havia resposta melhor. Um serviço restrito podia publicar override menor.

Zero significava desconhecido, não ausência de banda. MIN preservava zero diante de todos os valores positivos posteriores. Evidência ausente não virava recurso por otimismo acumulado.

Latência somava até a indeterminação

A latência local era o menor atraso de propagação e processamento, sem fila variável. Servia de base para a RFC 2212, mas não era RTT observado nem o limite C/R + D.

Uma nuvem deveria preferir valores por próximo salto. Um único valor usaria o menor caminho possível e poderia subestimar o real. Também era legítimo responder indeterminado.

Microssegundos eram somados até (2**32)-1. Esse valor distinguido significava contribuição incalculável ou overflow. Não era uma medição enorme e exata.

MTU usava MIN com entrada mais forte

O MTU local era o maior pacote IP sem fragmentação, incluindo cabeçalhos IP e superiores, excluindo os de enlace. Todo elemento consciente precisava fornecer valor correto. Um override de serviço podia reduzir, nunca aumentar, o MTU global.

Ainda assim, o resultado estava ligado a rota e serviço. Não provava envio, ausência de túnel oculto, estabilidade do caminho ou entrega.

TSpec não era uma quinta álgebra

O parâmetro 127 definia o token-bucket TSpec. Elementos intermediários não exportavam valores locais para compô-lo. Um contrato de tráfego no mesmo documento não se tornava medição de conformidade, admissão ou tratamento.

A caracterização ficava no meio da cadeia

RFC 1633, RFC 2205, RFC 2211, RFC 2212 e RFC 2216 tratavam de arquitetura, RSVP, serviços e modelo de especificação. Nenhuma camada transformava automaticamente o valor composto em resultado observado.

O registro auditável separa ID, ramificação, próximo salto, época da rota, fonte local, método, regra, estado desconhecido, solicitação, admissão, instalação, observação, entrega e resultado.

Fontes e limites

A fonte principal é a RFC 2215, com registros do RFC Editor e do IETF Datatracker. A RFC 2815 manteve depois, em IEEE 802, a distinção entre MTU exato e banda aproximada. Esses textos não provam adoção atual, produto, reserva ativa, desempenho ou incidente.

Os ensaios de Heng Lu sobre primazia do código em execução, especificação mínima e decisão local e camadas da realidade são lente editorial: uma afirmação orienta, mas não executa. Não são tese causal sobre 1997.