Resumo

  • A RFC 3474 propôs CALL_ID constante por toda a vida de uma Call ASON e distinguiu uma forma específica do operador de outra destinada à unicidade global.
  • A identidade pertencia à relação; Connections, estado RSVP, rótulos locais, recursos programados, sinal, tráfego e serviço continuavam sendo fatos independentes.

Uma chave de banco de dados pode atravessar uma falha sem que um único bit atravesse a rede. A RFC 3474, publicada em março de 2003 como Informational, documentou justamente a arquitetura capaz de produzir essa diferença. Ela não era Internet Standard: propunha extensões de GMPLS RSVP-TE para requisitos ASON, incluindo soft permanent connections, separação de Call e Connection, reinício e novos erros.

Call era a relação entre pontas, administrada por um Call controller. Connection era a realização com recursos, administrada por um Connection controller. Uma relação podia continuar enquanto suas Connections eram trocadas, interrompidas ou removidas. O registro de intenção e a infraestrutura de transporte não compartilhavam necessariamente o mesmo tempo de vida.

CALL_ID oferecia o fio de continuidade. Havia uma forma específica do operador e uma forma global. Esta reunia código de país ISO, código de operadora da UIT, código de ponto de acesso sob controle da organização, endereço do LSR de origem e identificador local. Os 64 bits locais deveriam permanecer constantes durante a Call.

O desenho parecia forte porque combinava várias autoridades de nomeação. Mas ele só distinguia Calls. Não reservava comprimento de onda, não configurava cross-connect, não acendia fibra e não transportava tráfego. Se o endereço do LSR tivesse apenas significado interno, nem mesmo a forma específica do operador se tornaria global por aparência.

A atribuição também tinha uma fronteira. O usuário inicial podia enviar CALL_ID zero. O primeiro nó da rede atribuía um novo valor ou verificava o valor existente. Nós intermediários o encaminhavam sem alteração, mesmo sem compreender a extensão ASON. Path, Resv, PathTear, PathErr e Notify podiam manter a mesma referência. Essa continuidade facilitava correlação, não congelava o estado das Connections.

Na separação básica, uma Call normalmente tinha uma ou mais Connections. Durante restauração break-before-make, podia passar transitoriamente por zero: a antiga era desfeita antes de a substituta existir. CALL_ID permanecia durante o vazio. Um painel que confundisse Call existente com circuito ativo apagaria o intervalo mais relevante para a operação.

A separação completa opcional tornava isso permanente e explícito. CALL_OPS permitia estabelecer ou sincronizar uma Call sem criar Connection no mesmo ato. O estado estável admitia zero, uma ou várias Connections. O zero não era contradição; era prova de que relação e conectividade tinham ciclos distintos.

SPC_LABEL mostrava limite semelhante. Numa soft permanent connection, associava o segmento de entrada permanente ao segmento comutado, mas a associação dependia de política local fora do documento. Em sub-redes não GMPLS, rótulos eram locais ao nó de controle e podiam ser provisionados manualmente ou descobertos. Uma associação local correta não comprovava continuidade ponta a ponta.

Após reinício, informação podia vir de armazenamento persistente, inferência do vizinho ou instrução de gestão. Recuperar CALL_ID demonstrava memória da relação. Não demonstrava concordância do vizinho, conclusão de RSVP, programação do equipamento, presença de sinal ou entrega de serviço.

Notify também não unificava as camadas. Uma notificação podia carregar sessões ligadas ao CALL_ID, e uma única mensagem podia conter sessões de várias Calls. Envelope, relação e estado de Connection precisavam ser correlacionados sem serem confundidos.

A cronologia posterior deve permanecer visível. A RFC 4139 tratou de aplicabilidade e requisitos ASON. A RFC 4974, Standards Track de 2007, definiu procedimentos mais completos e afirmou que a Call não fornecia conectividade de tráfego; podia ter zero, uma ou muitas Connections. A RFC 6004 acrescentou extensões UNI. Isso demonstra evolução, não implantação da proposta de 2003 nem autoridade retroativa.

Pela disciplina de Heng Lu, CALL_ID é símbolo coordenador; admissão da Call e sinalização da Connection são decisões de autoridades diferentes; recursos, sinal, tráfego e resultado da aplicação são realidade observada. A chave pode uni-los numa consulta, mas não pode emprestar prova de uma camada à outra.

O histórico confiável registra quem atribuiu CALL_ID, sua forma, escopo, endereço de origem e vigência. Cada Connection preserva identidade, intervalo de associação, mensagens RSVP, rótulos, recursos e desmontagem próprios. Depois vêm medições físicas, de tráfego e de serviço. Assim, a Call pode permanecer reconhecível sem fabricar a continuidade que apenas uma Connection observada poderia demonstrar.

Fontes