Resumo

  • RFC 1307 descreveu o DSLCP, protocolo Experimental de março de 1992 que permitia ao transporte pedir uma ligação cara apenas durante a sessão, deixando detalhes físicos e administrativos com outro controlador.
  • O provedor enxergava somente up e down; DSLCP guardava seis estados para representar comandos em voo, reversões de intenção, temporizadores, retransmissões e respostas fora de ordem.
  • Ao liberar uma ligação em Up, DSLCP mandava derrubar, entrava em Going Down e já avisava down; para o provedor, todo pedido de teardown recebia sucesso, sem esperar prova física.
  • Sucesso atrasado podia exigir uma ordem compensatória, falha por transação desconhecida podia ser tratada como sucesso local e aviso assíncrono de queda tinha origem própria. Nenhum desses fatos determinava sozinho capacidade, cobrança ou entrega de dados.

O painel foi desenhado para esquecer

O provedor de transporte tinha uma tarefa concreta: identificar quando começava e terminava o uso de uma sessão. As ligações comutadas permaneciam desligadas em condições normais, pois mantê-las ativas custava caro. A demanda de transporte oferecia, portanto, o momento econômico para conectar e liberar.

O provedor não precisava dominar os detalhes de equipamento e administração. Um controlador de ligação separado cuidava deles. Entre os dois, DSLCP escondia diferenças do controle de switches e mantinha o estado que o transporte não deveria acompanhar. RFC 1307 chegava a orientar o provedor a não rastrear o status particular da ligação, porque o protocolo poderia fazer redirecionamentos ou outros procedimentos invisíveis para cima.

Esse esquecimento era intencional. Reduzia acoplamento e dava ao transporte uma resposta compatível com sua função. O que o painel descartava, contudo, continuava existindo como sequência de controle — e continuava necessário quando a pergunta mudava de “posso seguir?” para “o que ocorreu fisicamente?”.

RFC 1307 foi publicado em março de 1992 para pesquisa adicional, com status Experimental. Nasceu de um projeto da Cray Research para controlar ligações de rede a jusante conhecidas por um host. A fonte descreve a arquitetura proposta; não é censo de uso atual nem registro de uma instalação concreta.

O comando viajava por uma rede que já precisava funcionar

Antes de preparar a ligação de dados, host e controlador precisavam dispor de outro caminho de rede. Mensagens DSLCP podiam usar datagramas IP ou UDP e não dependiam de transporte confiável. A via de comando estava de pé antes do recurso comandado.

Isso criava uma cadeia fácil de comprimir na fala e perigosa de comprimir na evidência. O usuário pedia conexão ou liberação. O provedor avaliava a quantidade de sessões. DSLCP enviava uma função. O controlador procurava a transação e agia sobre o hardware. Em outro plano, dados poderiam ou não circular. Cada verbo tinha seu autor e seu instante.

As mensagens continham identificador de 16 bits, dois endereços de extremidade de 32 bits, função, estado de evento e um corpo arbitrário cujo sentido cabia ao controlador. O identificador, combinado às duas extremidades, reconhecia uma transação de estabelecimento. Sozinho, não era nome global de circuito, sessão, pessoa ou autoridade.

O estado de evento também não valia sozinho. Ele descrevia a ligação em relação à última função solicitada: estabelecimento concluído ou falho, desmontagem concluída ou falha, além da queda assíncrona da rede. Separar “sucesso” da função anterior era guardar uma resposta e jogar fora a pergunta.

Seis estados preservavam as ações que se cruzavam

Para o provedor havia dois valores. Internamente, DSLCP tinha Down, Coming Up, Up, Going Down, Bring Down e Bring Up. Os nomes intermediários não eram enfeite. Eles permitiam que uma nova intenção chegasse antes de a anterior terminar.

Durante Coming Up, o controlador ainda devia concluir o estabelecimento. Se nesse intervalo viesse uma liberação, DSLCP passava a Bring Down. A subida já enviada não desaparecia; quando seu sucesso chegasse, o protocolo mandaria desmontar e entraria em Going Down.

Durante uma descida, podia ocorrer o oposto. Uma nova solicitação de conexão levava a Bring Up. DSLCP deixava a desmontagem pendente concluir e, em seguida, enviava uma nova ordem de subida. A intenção mais recente não reescrevia a mensagem anterior: esperava por ela e a compensava.

Esse arranjo aceitava que três setas apontassem para direções diferentes. O usuário atual queria subir. O controlador ainda derrubava. O provedor via o valor conveniente para sua sessão. A máquina de seis estados preservava a cronologia que a interface binária não exibia.

Down podia ser correto antes de ser físico

O estabelecimento exigia retorno individual: DSLCP informava ao provedor se aquele pedido havia funcionado ou falhado. A liberação obedecia a outro contrato. O provedor podia assumir sucesso, porque DSLCP sempre respondia positivamente ao seu pedido de teardown.

Quando estava Up e recebia uma liberação, DSLCP enviava a ordem de derrubar ao controlador, avançava para Going Down e notificava o provedor de que a ligação estava down. A notificação vinha antes da conclusão obrigatória do controlador. Ela declarava que, para a superfície de transporte, o recurso já não sustentava aquela demanda.

Não havia contradição em chamar isso de down dentro do contrato local. A contradição surgia ao transferir a palavra para outra autoridade. Contatos do circuito, capacidade disponível, cobrança encerrada e tráfego interrompido precisavam de observações próprias. A resposta do host não conseguia testemunhar por todos esses sistemas.

A rede sem garantia devolvia ecos

Sem transporte confiável, temporizadores e retransmissões faziam parte do protocolo. O ambiente dos autores usava cinco segundos de espera e três novas tentativas, mas o documento dizia que os valores deveriam ser ajustados. Pedidos redundantes podiam gerar respostas inesperadas; pacotes podiam chegar em ordem diferente da emissão.

Um sucesso de estabelecimento recebido em Down era tratado como possível eco de pedido duplicado ou pacote reordenado. DSLCP enviava então teardown. Se o mesmo sucesso aparecesse em Bring Down, o resultado também era ordem de desmontagem e passagem para Going Down. A mensagem talvez relatasse um evento autêntico, mas respondia a uma intenção vencida.

O cenário inverso revelava perda de sincronização. Um sucesso de teardown recebido em Up indicava que algum erro ocorrera. RFC 1307 preferia a atitude conservadora de derrubar e ressincronizar, embora observasse que ignorar a mensagem também poderia ser aceitável. As duas opções reconheciam que o evento não determinava uma única história física.

Repetição, atraso e inversão, portanto, não eram ruído descartável. Eram parte do mecanismo. Sem o estado anterior e a ordem pendente, uma compensação podia parecer uma falha nova, e um sucesso velho podia parecer confirmação atual.

Ausência de registro não era presença de acordo

Em Up, a falha de teardown tinha significado específico: DSLCP havia enviado uma solicitação para uma transação inválida e o controlador não encontrava registro correspondente ao identificador e às extremidades. A regra era continuar como se a solicitação tivesse sido bem-sucedida.

O protocolo escolhia uma saída local estável. Não afirmava que o controlador concordava, nem explicava se o circuito já caíra, se o registro fora perdido ou se nunca existira. “Como se” definia o comportamento seguinte da máquina; não recuperava o passado.

Havia ainda o aviso assíncrono de rede caída. O controlador podia emiti-lo fora da sequência comum de resposta. Em Coming Up, Bring Up ou Up, DSLCP ia para Down e avisava o provedor. Esse evento não era pedido de liberação feito pelo usuário nem sucesso de uma ordem de teardown. Preservar sua origem evitava atribuir uma queda a quem não a solicitou.

Nada no documento completava esses registros com segurança. A seção correspondente dizia que questões de segurança não eram discutidas. Endereços, identificadores, textos do controlador e respostas não sustentam, por essa fonte, garantias de autenticação, autorização, integridade ou confidencialidade.

Fonte e limites da evidência

A única fonte deste artigo é RFC 1307 — Dynamically Switched Link Control Protocol, de março de 1992. Aqui o foco é a interface binária sobre seis estados, com reversões, resultados fora de ordem e sucesso local de liberação. É diferente do artigo sobre RFC 1306, cujo mecanismo envolve busca de rota, ativação externa, proibição de dados antes do circuito completo, aliases de rota e temporizador separado antes do primeiro byte. RFC 1307 não prova controlador, link, sessão, teardown, segurança, capacidade, cobrança, tráfego ou resultado real.