Resumo

  • Depois de receber e processar Call Release, a RFC 3475 exigia iniciar a liberação de todas as Connections associadas.
  • Cada ramo ainda seguia Label Withdraw e Label Release; a confirmação da Call não provava desmontagem atômica, devolução física nem encerramento do serviço.

Uma ordem de fechar pode abrir uma fila de tarefas. A RFC 3475 mostrou isso no controle ASON em março de 2003.

O texto era Informational, não Internet Standard. Documentava pontos de código IANA para extensões CR-LDP escolhidas pelo trabalho ASON da UIT-T e deixava as regras de uso nos documentos da UIT-T. Registrava uma proposta, não implantação geral.

ASON separava Call, a relação, de Connections, as realizações com recursos. Uma Call podia conter várias. Call Setup e Call Release agiam no objeto superior; os procedimentos de rótulo continuavam atuando em cada ramo.

Call Release carregava Source ID, Destination ID e CALL_ID. Qualquer entidade de rede podia enviá-lo para terminar uma Call estabelecida. Uma Notification com código apropriado confirmava a liberação ao iniciador. Esse recibo, porém, permanecia no nível da Call.

Processar a mensagem deveria disparar a liberação de todas as Connections associadas. Cada uma usava os procedimentos CR-LDP comuns Label Release e Label Withdraw. Uma decisão virava várias transições entre pares, FECs e rótulos.

Na RFC 3036, o LSR downstream retira o mapeamento com Label Withdraw e o receptor responde com Label Release. Um LSR upstream também libera quando não precisa mais do mapeamento. Cada mensagem tem escopo próprio; nenhuma declara que todos os ramos desapareceram.

Três Connections podiam estar concluída, aguardando o par e ainda ativa. A obrigação de liberar todas não produzia atomicidade. A Notification da Call e a comprovação de cada Connection eram recibos diferentes.

Era necessário congelar a lista de associações no momento do release. Uma lista vazia consultada depois não informa quantos ramos existiram, quais repetiram a operação ou se algum sumiu do inventário antes de o equipamento devolver recursos.

CALL_ID correlacionava o conjunto, mas não certificava o fim. Não provava cada Withdraw, remoção de rótulo, capacidade devolvida pelo cross-connect, sinal encerrado, tráfego parado ou faturamento fechado.

Soft permanent connections preservavam outra fronteira. Segmentos usuário-rede podiam ficar provisionados enquanto o segmento de rede controlado era desmontado. Fechar a Connection comutada não descrevia toda a infraestrutura.

Crankback oferecia o contraste: uma Notification com ER-HOP localizava a falta de recurso para recalcular a rota. Localizar a barreira não provava recursos na alternativa nem sucesso da próxima tentativa.

Documentos posteriores, como a RFC 4974, não alteram retroativamente o status ou a semântica da RFC 3475. Também não provam uso por um operador real.

Nas camadas de realidade de Heng Lu, Call Release é instrução; seu processamento, decisão; cada troca de rótulo, recibo limitado; estado local, hardware, sinal, tráfego e serviço, observações separadas. O registro responsável preserva a foto das Connections e fecha cada ramo com evidência própria antes de encerrar a Call.

Fontes