Resumo

  • O RFC 2383 atribuía um circuito virtual ATM a um salto ST2+ e mantinha separados os planos de usuário, controle e gestão. O caminho reservado para os dados não era a mesma evidência que o caminho capaz de anunciar sua falha.
  • Como a recuperação de ST2+ era pouco clara e incompleta, e vários agentes podiam receber simultaneamente a notificação ATM, a especificação exigia NoRecover. Uma recusa explícita era mais interoperável que uma promessa sem autoridade compartilhada.

É possível reservar capacidade sem reservar o caminho de volta depois de uma falha.

Esse é o limite exposto pelo RFC 2383, publicado em agosto de 1998 como documento informativo para o transporte de ST2+ sobre ATM UNI 3.1. O mapeamento era direto: um salto ST2+ usava um circuito virtual ATM; o circuito não era compartilhado com outros saltos e o salto não era dividido entre vários circuitos. Uma solicitação abstrata de recursos ganhava um suporte identificável.

A recuperação não ganhou a mesma precisão. Toda implementação tinha de selecionar NoRecover em CONNECT. Uma solicitação em desacordo deveria receber REFUSE com o motivo NoRecover. O texto não chamava isso de recuperação automática parcial e não tratava a indicação de ATM como substituta da semântica ausente em ST2+. Declarava que a recuperação de fluxo não era suportada e que a aplicação deveria fornecê-la.

A escolha importa porque o ambiente já possuía várias peças que poderiam ser confundidas com recuperação. ATM podia indicar a perda de uma conexão. Agentes ST2+ trocavam SCMP. O FlowSpec reservava recursos salto a salto. Outro circuito podia ser estabelecido. Nada disso escolhia quem agiria, impedia tentativas simultâneas, associava necessariamente o substituto ao fluxo original ou provava um resultado aceito pela aplicação.

Um salto, um circuito, várias verdades

O RFC 2383 distinguia os planos de usuário, controle e gestão. Os dados ST2+ percorriam a conexão ATM atribuída ao salto. Os agentes trocavam SCMP no plano de controle. A gestão local escolhia endereços, estabelecia circuitos e observava seu estado.

Esses planos não precisavam ocupar um único caminho. A especificação não determinava o circuito virtual de SCMP: uma implementação podia reutilizar um VC de IPv4 ou criar outro dedicado ao controle ST2+. Os dados de um fluxo e suas mensagens SCMP precisavam seguir a mesma direção de roteamento ST2+, mas a rota IPv4 até o mesmo endereço IP podia ir no sentido oposto. O controle podia continuar alcançável com o circuito de dados rompido, ou falhar de forma independente.

Assim, dizer que “a rede está alcançável” tinha pouco valor sem nomear o objeto. Um pacote IPv4 encontrou uma rota? SCMP chegou ao agente? O comutador ATM ainda guardava o estado da chamada? Os dados de usuário atravessavam aquele VC específico? Cada resposta pertencia a uma camada e não certificava automaticamente as demais.

A regra de um VC por salto tornava a evidência concreta e local. O circuito era o suporte daquele trecho. Um fluxo de ponta a ponta dependia de vários saltos, circuitos e agentes. A perda de um VC localizava o segmento quebrado; não reconstruía o fluxo inteiro.

Detectar a falha não coordenava a recuperação

A função HELLO de ST2+ podia não ser suportada sobre ATM, pois se esperava que ATM fornecesse notificação adequada da falha de conexão. Mas dados e SCMP podiam percorrer VCs distintos. Uma confirmação de vida em um caminho não demonstrava o estado do outro.

Na recuperação, a separação se tornava crítica. O RFC 1819 descrevia recuperação em ST2+, mas o RFC 2383 a considerava pouco clara e incompleta para esse ambiente. ATM podia notificar todas as partes afetadas. Vários agentes ST2+ podiam então detectar a mesma falha quase ao mesmo tempo.

Se cada um agisse sozinho, suas ações competiriam. Um agente poderia liberar o estado antigo enquanto outro reconstruía; dois segmentos substitutos poderiam aparecer; o trecho posterior poderia se ligar à tentativa errada. Não bastava um gatilho. Eram necessários uma regra de autoridade, uma identidade comum de recuperação, uma ordem de operações e recibos separados para detectar, liberar, admitir, reconstruir e obter a aceitação da aplicação.

O RFC 2383 não fornecia esse contrato interoperável. NoRecover nomeava a superfície de controle que faltava. Um comutador podia dizer com verdade que o VC desapareceu, um agente que recebeu o alerta e um circuito novo que foi admitido. A aplicação ainda podia enfrentar uma lacuna, uma duplicação ou a ausência do fluxo pretendido.

A aplicação herdou a obrigação final

Dizer que a aplicação devia fornecer recuperação não lhe dava uma capacidade mágica. Transferia o problema à camada que conhecia o significado de continuidade. Para uma aplicação, recuperar podia ser retomar a partir de um número de sequência. Para outra, podia exigir um fluxo novo e o descarte do resultado parcial. Um efeito não repetível talvez exigisse decisão humana.

A rede podia oferecer outro caminho, mas não sabia se o antigo e o novo formavam uma única operação válida. Portanto, o sucesso ao estabelecer um VC substituto não justificava “recuperado”. A prova precisava juntar a indicação de falha, as identidades dos dois circuitos, a liberação da reserva antiga, a reconstrução do salto ST2+, a identidade do fluxo de ponta a ponta e o recibo da aplicação.

A lente das camadas de realidade de Heng Lu torna o erro mais visível. Estado físico, chamada ATM, estado do agente ST2+, troca SCMP, sessão de aplicação e resultado do usuário são relacionados, não sinônimos. Comprimi-los em uma luz verde deixa o painel claro ao eliminar as diferenças que decidem se a afirmação é verdadeira. Quem controla o rótulo “restaurado” pode não ser quem suporta a perda ou a repetição.

A direção do estabelecimento também era política

Mesmo antes da falha, o circuito precisava de um iniciador. Nos circuitos virtuais comutados, o RFC 2383 permitia escolher a parte que iniciaria a conexão ATM conforme a política operacional ou de cobrança. Essa direção era independente da orientação emissor–receptor usada na construção do fluxo ST2+.

Quem pagava podia iniciar a chamada; quem construía o fluxo podia esperar uma ação do próximo salto; e o primeiro agente a ver a falha talvez não tivesse autorização para criar um novo circuito cobrado. Um desenho que ignora esses poderes e incentivos pode parecer tecnicamente plausível e ser operacionalmente impossível.

O mapeamento do FlowSpec para parâmetros ATM tinha outra borda rígida. Características de tráfego e qualidade de serviço eram traduzidas com base nos modelos dos RFCs 2211 e 2212 e na sinalização do RFC 1755. UNI 3.1 não permitia alterar a QoS de uma conexão já estabelecida. Se uma mudança admitida de FlowSpec exigisse outros recursos, a implementação deveria liberar as conexões ATM antigas e criar novas.

Isso não era uma edição no mesmo lugar, mas uma passagem de custódia entre duas alocações. Quando o circuito antigo cessava, quando o novo era admitido e o que sobrevivia a uma falha dependiam da implementação e da política. O RFC definia o mapeamento e a necessidade de reconstrução, mas não publicava medição de transição sem perda nem prova de continuidade da aplicação.

Essa fronteira separa esta história da do RFC 2380. Ali, o problema central era a mudança de reserva, a reduced reservation e o compromisso entre a alocação velha e a nova. No RFC 2383, a questão própria é outra: vários agentes veem a falha ATM, mas o protocolo não dispõe de uma autoridade completa de recuperação.

Recusar explicitamente também era interoperar

É fácil ler NoRecover como uma função inacabada. Era também uma decisão positiva. Se uma implementação executasse uma sequência privada e a outra interpretasse o mesmo estado de outra maneira, poderiam surgir duplicatas, reservas órfãs ou dois sentidos incompatíveis para o fluxo.

A marca obrigatória expunha o limite durante o estabelecimento. A solicitação recebia REFUSE com um motivo nomeado, em vez de esconder a divergência até uma pane futura. Uma interface que falha com precisão é mais segura que outra cujas pontas não compartilham a definição de sucesso.

Na perspectiva da especificação inicial mínima de Heng Lu, tratava-se de incompletude disciplinada. Uma especificação mínima não deve cobrir terreno não comprovado com palavras parecidas com garantias. Ela define o núcleo compartilhado, localiza a decisão privada e deixa que código em funcionamento demonstre um contrato mais forte. Circuitos dedicados, endereçamento, estabelecimento e mapeamento de recursos pertenciam ao núcleo; a recuperação de fluxo não.

Remover NoRecover exigiria mais que um novo parágrafo. Seria preciso entregar o mesmo alerta ATM a vários agentes, demonstrar a escolha de uma só autoridade, suprimir duplicações, acertar a reserva antiga, estabelecer o substituto, uni-lo ao fluxo correto e devolver à aplicação um resultado inequívoco. Os testes deveriam perder mensagens de controle, inverter direções e derrubar separadamente os VCs de dados e controle.

O RFC 2383 não reivindicava tais resultados. Seu status informativo também limita a conclusão histórica: era uma especificação de protocolo, não um levantamento de implantação. O histórico do IETF Datatracker mostra o percurso do documento, não adoção ampla.

A segurança protegia uma borda da cadeia

A seção de segurança também era delimitada. As extensões mínimas de ATM e as correções não deveriam enfraquecer ST2+ nem UNI 3.1. Um número da parte chamadora fornecido e verificado pela rede podia contribuir para a autenticação.

Contribuir não significava completar. A identidade do chamador podia ajudar a reconhecer o iniciador, mas não demonstrava que o FlowSpec estava autorizado, que o novo VC pertencia ao fluxo que falhou ou que a aplicação aceitava a sessão reconstruída. Identidade, recursos, estado e resultado pediam evidências complementares.

O documento também não prova que certo operador implantou o protocolo, que um circuito cumpriu uma latência, que um incidente real foi recuperado ou que uma política de cobrança escolheu determinada parte. Esses fatos exigem registros de operação próprios.

A fronteira histórica é mais duradoura: reserva de recursos, detecção de falha, alcance do controle, reconstrução e sucesso da aplicação são cinco afirmações diferentes. As três primeiras podem existir sem a quarta; a infraestrutura pode ser reconstruída sem a quinta. Em 1998, o RFC 2383 preservou essa distinção com uma marca direta: NoRecover.

Ela não dizia que nada podia ser feito depois da falha. Dizia que a rede não deveria prometer uma recuperação concluída antes de compartilhar sua autoridade, ordem e recibo final. O circuito podia reservar os recursos. Os agentes podiam saber que ele se rompeu. O significado de recomeçar continuava pertencendo à aplicação.

Fontes