Resumo

  • A RFC 3476 inseriu objetos da UNI óptica do OIF nos espaços públicos de LDP e RSVP, mas remeteu conteúdo e uso à especificação do OIF.
  • Diversidade ou nível de serviço podiam estar indisponíveis, a conexão podia ser desconhecida e remetente ou destinatário podiam não ter autorização; reconhecer o código era só o começo.

Um registro de protocolo administra uma coisa minúscula: o significado de um número. Esse trabalho é essencial porque duas implementações que leem o mesmo valor de formas diferentes não conseguem cooperar. Quando o registro resolve a ambiguidade, elas passam a saber o que foi pedido. Ainda não sabem se o pedido deve ser aceito, se há recurso ou se o serviço foi realizado.

Publicada em março de 2003, a RFC 3476 era Informativa, não um Padrão da Internet. O Optical Internetworking Forum havia especificado a sinalização de uma interface óptica usuário-rede, a UNI. O objetivo era reaproveitar ao máximo LDP, RSVP, RSVP-TE e GMPLS. Algumas necessidades específicas da UNI, porém, precisavam de identificadores novos dentro de protocolos da IETF.

No lado LDP, surgiram três TLVs Source ID e três Destination ID, em formas IPv4, IPv6 e NSAP. Vieram também Egress Label, Local Connection ID, Diversity, Contract ID e UNI Service Level. Os valores ocupavam 0x0960 a 0x0970. No lado RSVP, GENERALIZED_UNI recebeu class number 229, C-Type 1, e UNI_IPv4_SESSION recebeu class 1, C-Type 11. Os subobjetos carregavam TNA de origem e destino, diversidade, rótulo de saída e nível de serviço.

O catálogo numérico não fingia ser toda a especificação. Para vários campos, a RFC dizia que conteúdo e uso estavam descritos no documento UNI do OIF. O número público dava um ponto de referência estável. O acordo externo dava a semântica. A rede operacional ainda precisava confirmar identidade, autoridade, política e disponibilidade.

Também havia uma divisão institucional. OIF produzia o acordo voltado ao serviço; IETF fornecia protocolos reutilizáveis; IANA protegia espaços de valores contra colisão; fabricantes implementavam; operadores controlavam topologia e capacidade. A publicação da RFC não transformava automaticamente a oferta do OIF em padrão da IETF. O registro na IANA tampouco obrigava uma rede a aceitar a solicitação.

Nem tudo foi para o espaço público. Códigos de status LDP específicos da UNI ficaram no espaço de uso privado 0x3Fxxxxxx, sem administração da IANA. Status Enquiry e Status Response, duas mensagens definidas antes pelo OIF, já estavam obsoletas e não receberam números. O registro era resultado de uma seleção: alguns elementos ganharam identidade pública, outros continuaram privados e outros morreram antes da atribuição.

Os erros RSVP revelam o limite de maneira direta. A rede podia informar Diversity not available, Service level not available ou Invalid/Unknown connection ID. Policy Control Failure podia distinguir Unauthorized sender de Unauthorized receiver. Nenhum desses casos era incapacidade de ler o código. Eram decisões tomadas depois da leitura correta.

Um objeto GENERALIZED_UNI pode ter class, C-Type, comprimento e subobjetos válidos. As TNA podem ser bem formadas. Isso não prova que o remetente tenha poder contratual, que o destinatário concorde, que existam duas rotas de fato independentes ou que haja capacidade livre. Validade sintática e viabilidade operacional são recibos diferentes.

O ponto de código diz “interprete estes bits como este objeto”. Não diz “obedeça a este ator”, “aceite este contrato”, “reserve este comprimento de onda” ou “declare o cliente atendido”. Quando tudo vira um único estado verde, o comprovante do registro toma emprestada a autoridade das decisões posteriores.

Os protocolos próximos preservavam a separação. RSVP mantinha estado de reservas; RSVP-TE acrescentava túneis; LDP distribuía rótulos; GMPLS generalizava o rótulo para recursos além de pacotes. As RFCs 3471 a 3475 separavam identidade, trocas, notificações, Calls e Connections. A RFC 3476 conectou o vocabulário UNI a esses espaços; não apagou as etapas.

Mais tarde, a RFC 3936 organizou políticas de atribuição RSVP e a RFC 8126 reforçou que instruções à IANA devem ser separadas da documentação técnica. Esses textos posteriores não podem ser tratados como regras integrais de 2003. Eles ajudam, contudo, a descrever o ofício já visível: registrar uma referência não é executar o que ela nomeia.

Os registros atuais da IANA provam que houve uma atribuição e preservam sua referência. Não são telemetria. Não mostram se o cálculo encontrou diversidade, se a capacidade foi reservada, se um cross-connect óptico mudou, se havia sinal ou se o tráfego passou.

A disciplina de camadas de realidade de Heng Lu começa pela mensagem bruta. Devem ser preservados número, protocolo, comprimento, bits U/F ou class/C-Type e resultado do parser. Em seguida, é preciso resolver o valor no registro datado e abrir exatamente as versões RFC e OIF aplicáveis. Identidade, autenticação, autorização, admissão, rota, reserva, programação física, sinal, tráfego e resultado de serviço entram como evidências separadas.

Source ID legível não é autoridade autenticada. Diversity solicitado não é diversidade entregue. Service Level não é SLA cumprido. Egress Label não é recibo físico. Ausência de erro também não constitui confirmação positiva de todas as ações seguintes.

O caminho de rejeição merece o mesmo cuidado: objeto de erro, código, subcódigo, nó emissor, horário e pedido correlacionado. “Diversity not available” é melhor do que uma falha genérica, pois nomeia a superfície da recusa. Ainda não prova toda a topologia oculta nem elimina a possibilidade de base de recursos desatualizada.

A RFC 3476 entrou para a história porque mostrou uma forma estreita e útil de coordenação. Um registro público permite que implementações independentes nomeiem o mesmo objeto. Isso é infraestrutura necessária. Não é soberania sobre o serviço e não é prova de que o serviço existiu. O número abre o processo; os recibos das demais camadas precisam encerrá-lo.

Fontes