Resumo

  • A RFC 3477 combinou um Router ID estável com um Interface ID local ao extremo para que o RSVP-TE pudesse especificar e registrar enlaces ponto a ponto não numerados.
  • As duas pontas podiam escolher valores sem relação entre si; intenção ERO, resolução IF_ID, registro RRO e encaminhamento real continuavam sendo recibos separados.

“Não numerado” parece descrever ausência de identidade. Na RFC 3477, o enlace possuía duas. Cada LSR nas pontas atribuía seu próprio nome, e nenhum dos dois números podia representar o enlace fora do contexto do equipamento que o criou.

O enlace precisava ser ponto a ponto. Cada LSR escolhia um valor de 32 bits diferente de zero e garantia unicidade apenas no seu próprio escopo. A especificação dizia não existir relação prévia entre os valores das duas pontas. Visto de A, o número de A era local e o de B remoto; visto de B, as palavras trocavam de lugar. A perspectiva fazia parte do dado.

Por isso, o nome útil era uma dupla. O Interface ID seguia acompanhado do Router ID do LSR que o havia atribuído. Esse Router ID era um endereço IP estável, normalmente um loopback, destinado a permanecer alcançável sempre que houvesse alguma conectividade com o roteador. O contexto transformava uma cifra local em referência transportável sem fingir que ela era global.

Dois roteadores podiam reutilizar o mesmo número sem colisão porque seus Router IDs eram distintos. Ao mesmo tempo, um único enlace podia carregar números diferentes em cada ponta sem inconsistência. Forçar os valores a coincidir não seria limpeza cadastral; apagaria o registro de quem tinha autoridade para nomear cada lado.

Os extremos ainda precisavam trocar suas atribuições. A RFC citava configuração, LMP, RSVP ou CR-LDP no caso de uma forwarding adjacency e extensões de IS-IS ou OSPF. Quando o IGP apoiava engenharia de tráfego, seus módulos e o RSVP dentro do mesmo LSR tinham de concordar sobre os valores. Um formato correto não corrigia um mapa de vizinhos desatualizado.

O primeiro uso era a intenção de rota. Um subobjeto Unnumbered Interface ID foi acrescentado ao Explicit Route Object, com tipo 4 e comprimento 12. Ele carregava Router ID e Interface ID. No ERO, a dupla dizia qual enlace não numerado deveria ser usado. Era uma instrução para a construção do caminho, e não uma prova de travessia.

Depois vinha a resolução pelo vizinho. Ao selecionar uma saída não numerada, o nó incluía em IF_ID RSVP_HOP seu Router ID e o identificador local. O LSR receptor precisava conhecer os números atribuídos por seus vizinhos e procurar uma correspondência. Sem ela, a RFC recomendava IF_ID ERROR_SPEC com código 24 e valor 16, “Unknown Interface Index”.

O erro delimita a realidade conhecida. Ele mostra que um receptor, naquele momento, não conseguiu resolver aquele nome de escopo vizinho. Não prova que a fibra não existia, que o emissor mentia, que todo o IGP estava errado ou que não havia alternativa. Para atribuir a causa, são necessárias a origem do mapeamento, sua versão, a direção da mensagem e o estado da adjacência.

O Record Route Object reutilizava um subobjeto de tipo 4 e comprimento 12 para uma finalidade diferente. O ERO descrevia onde o RSVP pretendia passar; o RRO acumulava o caminho registrado pelo plano de controle. Codificação parecida não transformava intenção em observação, nem observação RSVP em telemetria física independente.

Os bits de proteção tornavam a diferença mais visível. Um indicava proteção local disponível; outro, proteção local em uso, normalmente porque um reparo mantinha o túnel após uma falha. Ter capacidade de proteção e ativá-la eram acontecimentos distintos. Um sistema que registra apenas “protegido” perde a transição que explica o incidente.

As forwarding adjacencies também seguiam o modelo. Um LSP anunciado como enlace não numerado recebia um identificador na cabeça e outro na cauda. O objeto LSP_TUNNEL_INTERFACE_ID, classe 193 e C-Type 1, podia levar a identidade de ida no Path e a de volta no Resv. Mesmo um enlace construído sobre outro LSP preservava dois pontos de vista administrativos.

Documentos posteriores de GMPLS, OSPF, IS-IS e agregação de enlaces ampliaram a publicidade ou o uso desses identificadores. A RFC 6107 atualizou depois a RFC 3477 para Path Keys. Eles esclarecem a linhagem técnica, mas não demonstram que uma rede de janeiro de 2003 implementava recursos futuros ou que um caminho específico funcionou.

A disciplina de camadas de realidade nas notas de Heng Lu impede que um registro tome emprestada a autoridade de outro. Router ID dá escopo, não prova alcançabilidade atual. ERO declara intenção, não trânsito. RRO registra estado RSVP, não continuidade física. Alocação de rótulo não é programação de hardware, e programação não é entrega de tráfego.

Uma auditoria deve preservar mensagem RSVP bruta, sessão, remetente, direção e tempo; ordem ERO, dupla IF_ID, fonte do mapa de vizinhos, resultado da busca, estados Path e Resv, operação de rótulo, ordem RRO e flags. Só depois deve ligar esses dados ao inventário, às adjacências, à tabela de encaminhamento, aos alarmes e aos contadores, cada qual com sua própria procedência.

A regra operacional decisiva é nunca separar Interface ID do Router ID que o atribuiu. Tampouco se deve transformar os dois valores das pontas em um número canônico inventado. A diferença não é ruído: é a marca deixada pela distribuição do poder de nomear.

A RFC 3477 ocupa um lugar na história da Internet porque coordenou pluralidade sem suprimi-la. Um sistema distribuído não precisava começar por um nome universal. Precisava transportar o escopo, preservar as duas perspectivas e distinguir o pretendido, o resolvido, o registrado e o efetivamente encaminhado. O enlace não numerado não era anônimo; seus nomes eram corretamente locais.

Fontes