Resumo

  • O PPP comum continuava usando quadros UI sem recuperação obrigatória. O Numbered Mode do RFC 1663 era negociado voluntariamente por LCP para um único enlace e acrescentava janela limitada, sequência, confirmações, temporizadores e uma volta definida ao modo não numerado.
  • Cada ponta podia anunciar uma janela diferente, mas as duas tinham de usar o mesmo módulo: 8 para janelas menores que 8, 128 para as demais. Magic-Number escolhia quem iniciava SABM ou SABME; não autenticava o par.
  • SABM ou SABME seguido de UA estabelecia o procedimento numerado. Autenticação, avaliação de qualidade, NCP, roteamento e resultado da aplicação continuavam sendo afirmações independentes.

Uma perda podia desalinhar todo o contexto

No PPP sobre enquadramento semelhante a HDLC, o formato ordinário usava o endereço All-Stations e o controle Unnumbered Information. Os pacotes eram datagramas. Um quadro danificado podia ser descartado sem que a camada de enlace prometesse recolocá-lo em ordem.

Essa simplicidade funcionava quando cada datagrama era autônomo. O RFC 1663 destacou a compressão como caso diferente. Emissor e receptor podiam manter um dicionário comum; a perda de um datagrama comprimido deslocava esse estado e tornava incompreensíveis quadros posteriores, mesmo íntegros. Alguns métodos reiniciavam o contexto com baixo custo. Outros se beneficiavam de entrega ordenada e confiável entre os dois vizinhos.

O grupo PPP do IETF não tornou essa despesa universal. Publicado em julho de 1994, o RFC 1663 definiu a opção LCP 11, Numbered-Mode. Uma ponta precisava pedi-la durante o estabelecimento e a outra aceitá-la. Sem acordo, o modo UI permanecia o padrão.

O consenso foi deliberadamente pequeno. Implementações que não precisavam de recuperação mantinham o formato econômico. Pares que compartilhavam estado frágil podiam assumir janela e retransmissão sem transformar uma necessidade local em regra para todos.

Address e Control passaram a carregar estado

Numbered Mode não substituía o pacote PPP inteiro. Protocol, Information, Padding, FCS e flags mantinham suas funções. Address e Control passavam a expressar o procedimento LAPB numerado de ISO 7776. Depois da entrada no modo, todos os quadros daquele enlace tinham de usá-lo; UI não podia ser misturado por conveniência.

Isso eliminava Address-and-Control-Field Compression. No formato comum, o par constante ff 03 podia sumir. No formato numerado, os dois campos carregavam endereço e controle de sequência. O RFC 1663 proibia ACFC, e o RFC 1662 dava a regra mais ampla: valores diferentes de Address ou Control exigem definição ou acordo e não podem ser comprimidos como os valores usuais.

O FCS abrangia esses campos. Um FCS correto sustentava a integridade local dos bits, não a conclusão de que os dois lados ainda compartilhavam o mesmo estado negociado. Um quadro pode estar intacto e pertencer a uma época que o receptor já abandonou.

A janela também escolhia a linguagem de sequência

Window variava de 1 a 127. O valor dizia quantos quadros o receptor podia armazenar e quantos o emissor podia manter sem confirmação. Era capacidade e, ao mesmo tempo, um teto para trabalho incerto.

Janelas abaixo de 8 usavam módulo 8; janelas de 8 ou mais usavam módulo 128. As pontas podiam declarar janelas distintas, pois seus buffers podiam ser assimétricos. Não podiam declarar módulos distintos. Contar num círculo de três bits e interpretar num círculo de sete bits não é uma diferença de desempenho: é falar duas sintaxes incompatíveis.

Configure-Nak podia sugerir uma janela menor, nunca maior. Assim, o receptor limitava sua obrigação aos próprios recursos, e uma resposta não empurrava o solicitante para um formato mais largo do que ele havia oferecido.

A opção ainda carregava um endereço HDLC. Zero precisava ser recusado com uma alternativa adequada. Regras de desempate comparavam janelas e endereços antes de recorrer a uma escolha aleatória. O resultado coordenava os papéis no enlace; não identificava a pessoa, a empresa ou o operador por trás do equipamento.

Magic-Number determinava quem falava primeiro

O modo exigia negociação bem-sucedida de Magic-Number. Após a aceitação por LCP, a ponta com o menor número enviava SABM no módulo 8 ou SABME no módulo 128; a outra respondia UA. Os vizinhos escolhiam um iniciador sem precisar de um árbitro adicional.

Perda do pedido ou de UA acionava os parâmetros de Restart Timer e contagem de LCP. UA, porém, fechava apenas aquele estabelecimento. Na arquitetura PPP, autenticação, Link Quality Determination e configuração de NCP vinham depois. UA não provava credenciais aceitas, qualidade suficiente, IP configurado, rota ativa ou uma operação executada no destino.

Magic-Number também não era credencial. Ajudava a diferenciar as pontas e detectar loopback, mas não era assinatura nem autorização. O RFC 1663 não discutia segurança. Confiabilidade da entrega vizinha e confiança na identidade do vizinho continuavam separadas.

Perder o estado tinha uma saída comum

Uma retransmissão interoperável precisa definir como reconhecer que o estado compartilhado acabou. O RFC 1663 não deixava uma ponta numerada conversar indefinidamente com outra em UI.

A renegociação começava ainda no modo numerado. Se a opção não fosse aceita outra vez, o enlace voltava a UI antes de autenticação, qualidade e NCP. Uma implementação capaz, mas atualmente não numerada, ao receber um quadro não-UI com FCS correto, respondia DM e reiniciava LCP. Uma ponta numerada que recebesse DM também voltava a UI e enviava novo Configure-Request.

Um bom FCS, portanto, não ressuscitava sozinho um estado antigo. DM e a nova negociação tornavam a divergência observável.

O ciclo de tentativas era limitado. T1 definia a espera máxima por resposta a um quadro de informação antes da retransmissão. A recomendação era ajustá-lo ao tempo de ida e volta LAPB medido; a alternativa usava tamanho do quadro, taxa de bits e tempo de processamento. T3 indicava ociosidade e precisava ser maior que T1. N2 limitava as transmissões de um quadro; ultrapassá-lo deveria encerrar o enlace, com 3 como padrão recomendado.

Três não era uma regra para todos os serviços. Era o limite inicial dessa recuperação adjacente. O esgotamento de N2 não explicava a causa do silêncio e não determinava o orçamento de repetição de uma transação da aplicação.

Enlaces paralelos continuavam separados

Por padrão, enlaces PPP paralelos eram estabelecidos, configurados e terminados independentemente. Um contexto de compressão dependente de ordem também ficava preso a cada enlace até que outro procedimento os unisse.

O RFC 1663 mencionou o ISO Multi-Link, desaconselhou sua implementação e apontou para o trabalho PPP Multilink que se tornaria o RFC 1990. Numbered Mode recuperava ordem em um enlace membro. Multilink criava uma sequência de feixe para remontar fragmentos distribuídos entre membros. Um mecanismo não era evidência do outro.

Cada confirmação numerada pertence, assim, a um enlace, endereços, módulo e época de negociação. Ela não migra para um enlace paralelo e não atravessa roteadores como recibo fim a fim.

A confirmação era útil porque conhecia seu limite

O registro da IANA associa Numbered-Mode à opção LCP 11. Isso fixa o vocabulário. Configure-Ack prova a aceitação de valores concretos numa negociação. SABM ou SABME com UA prova o estabelecimento do procedimento. Sequências, confirmações e retransmissões sustentam afirmações sobre quadros daquele enlace. DM, reinício de LCP ou esgotamento de N2 mostra a perda do estado.

Nenhum degrau substitui o próximo. Identidade precisa de autenticação; qualidade precisa de medidas e política local; configuração de rede precisa de NCP; alcance precisa de roteamento; conclusão precisa de identificador e resposta da própria aplicação.

A realização histórica do RFC 1663 foi um contrato modesto e verificável. Dois vizinhos que desejavam confiabilidade compartilhavam uma linguagem de sequência, limitavam pendências, reconheciam progresso e tinham uma forma comum de recomeçar. A confirmação parava no enlace e, por isso, dizia com precisão o que de fato havia observado.

Fontes