Resumo

  • O identificador da parte chamada escolhia um serviço entre vários números ligados ao mesmo acesso, mas não autenticava o chamador nem autorizava PPP.
  • Se LCP não tivesse recebido Open administrativo, RFC 1618 mandava rejeitar a chamada; aceitar para fechar depois ou ignorar pacotes era proibido.
  • Aceitação, codificação, enquadramento, Up, LCP Opened, autenticação, NCP e efeito da aplicação eram comprovantes diferentes.

Um seletor, não um comando

RFC 1618, de maio de 1994, tratou PPP sobre circuitos comutados ISDN sem pressupor uma rede mundial homogênea. O texto reconheceu a variedade de centrais, equipamentos e políticas de assinatura e escolheu poucos padrões iniciais para interoperabilidade.

O canal B era um portador ponto a ponto adequado a PPP; uma PRI podia manter vários simultaneamente. O canal D também podia levar PPP com o enquadramento certo, mas tinha menor capacidade e frequentemente alcance apenas até a central local. Essa disponibilidade física não dizia qual serviço o terminal aceitaria.

Vários números de diretório podiam terminar na mesma instalação. Cada número era associado administrativamente a um serviço, e a central local fornecia o identificador chamado. Ele respondia qual porta fora escolhida. Não respondia quem chamava, se o serviço estava habilitado ou se os pares conseguiriam negociar.

O sinal mais descritivo não chegava inteiro

O LLC Information Element parecia capaz de anunciar enquadramento ou codificação fora da banda. A experiência registrada no RFC mostrou o contrário: poucas centrais compatíveis o preservavam de ponta a ponta, e as políticas dos provedores eram diversas. Não havia valor LLC-IE atribuído a PPP; outros valores podiam ser ignorados e não deveriam definir seu modo.

O limite vinha do caminho institucional do dado. Um campo não se torna autoridade comum quando cada intermediário decide se o transporta. RFC 1618 preferiu uma indicação local de alcance menor e deixou a decisão operacional onde suas consequências seriam suportadas.

Open tinha um autor local

Quando o identificador chamado era usado — ou se futuramente chegasse um valor LLC de PPP — a ausência de Open administrativo em LCP exigia rejeição. O receptor não podia aceitar o circuito e fechá-lo em seguida, nem aceitar e ficar mudo.

RFC 1548 e RFC 1661 definem Open como a permissão de um administrador, humano ou programa. Up é a disponibilidade informada pela camada inferior. Opened é o estado alcançado depois da troca de configuração LCP. A central, a política local e os dois pares eram autoridades diferentes.

A recusa antecipada poupava um canal comutado e preservava causalidade. Depois da aceitação, silêncio podia parecer falha de quadro, par ausente ou perda. Antes dela, a recusa dizia que o serviço local não fora aberto.

Descobrir custava tempo e circuito

Mesmo autorizado, o terminal podia desconhecer a representação dos bits. Para o PPP, o canal ISDN era um enlace síncrono de dúplex integral, mas codificação e embaralhamento pertenciam ao equipamento DTE/DCE. RFC 1618 indicava NRZ como padrão no ponto T, NRZI como alternativa configurada e desaconselhava NRZ invertido.

A detecção automática percorria modos. Em cada um, enviava duas LCP Configure-Request, aguardava resposta e só então avançava. O total não podia passar de 59 segundos; 30 segundos era preferível. O algoritmo não lia uma verdade escondida: fazia experimentos com orçamento.

Sem configuração prévia, o canal B começava com HDLC síncrono a bits. HDLC síncrono a octetos dependia de limites de octeto disponíveis e configuração. Vários enquadramentos não deveriam concorrer no mesmo canal. RFC 1549 ainda ligava NRZI à perda de propriedades do FCS de 16 bits e recomendava negociar 32 bits.

Para esse uso, o documento tornou V.120 obsoleto porque seu enquadramento podia ser difícil de distinguir de Frame Relay e recomendou transportar PPP dentro de Frame Relay. Era uma escolha delimitada de interoperabilidade, não prova do método usado em uma chamada específica.

A fila podia virar discador

O RFC recomendava MTU de camada de rede não superior a 1500, salvo quando uma MRU de pelo menos 2048 fosse negociada expressamente com o par. Também recomendava recuo exponencial do temporizador de 250 milissegundos a três segundos e limites para discagem persistente. Após falha de estabelecimento, descartar a fila transmitida podia remover temporariamente o pacote que estimulava nova chamada.

Sem limite, um pacote pendente gerava chamadas repetidas. Sem registro antes da limpeza, a solução apagava a origem da repetição. A política precisava governar tanto persistência quanto evidência.

RFC 1618 preferia PPP Multilink a BONDING, cujo estágio próprio de inicialização interferia na detecção. RFC 1990 depois definiu bundles para capacidade sob demanda, mas vários canais só se tornavam um enlace lógico após negociação LCP.

A chamada aceita ainda não era tráfego útil

Depois da admissão vinham enquadramento compatível, camada inferior Up, LCP Opened, autenticação se escolhida, NCP Opened e só então datagramas. A entrega do datagrama ainda não era o resultado da aplicação.

O registro do RFC Editor prova publicação, autoria e o rótulo atual Proposed Standard, não implantação ou comportamento atual. O documento não discute segurança; o número chamado não autentica o chamador.

A primazia do código em execução de Heng Lu separa declaração de efeito. Sua especificação inicial mínima mostra por que padrões comuns podiam permanecer pequenos enquanto a adoção era local.

A central indicou o serviço. O terminal reteve o direito de dizer não. RFC 1618 colocou esse não antes da ocupação do circuito, tornando política diferente de pane.

Fontes