Resumo

  • O Header-Last permitia observar o tamanho depois da compressão antes de marcar se o pacote SDTP iniciava, continuava ou encerrava um quadro serial.
  • Os bits de segmentação da RFC 1963 eram B/F; E indicava a extensão CS, e SDTP não tinha campo de sequência. B/E com número de sequência pertenciam ao PPP Multilink da RFC 1990.
  • Length separava pacotes em um quadro PPP composto e Port selecionava um canal negociado, mas nenhum deles comprovava ausência de perdas, identidade física do porto ou recuperação do serviço.

Em desenhos de protocolo, o cabeçalho costuma vir primeiro. A RFC 1963, publicada como Informational em agosto de 1996, adotou a ordem contrária no formato padrão do Serial Data Transport Protocol. Os dados transportados apareciam no início; o cabeçalho de Terminal Adaptation surgia no fim, com seus octetos em ordem invertida. Para interpretar o pacote, o receptor precisava trabalhar a partir das duas extremidades.

Essa forma respondia ao momento em que o transmissor dispunha da informação necessária. O trabalho que levou ao protocolo incluía compressão de dados síncronos em DSU/CSUs. Quando um quadro serial comprimido precisava ser dividido em vários pacotes SDTP, o tamanho útil podia não estar disponível antes de o compressor produzir sua saída. Um cabeçalho inicial exigiria uma decisão prematura sobre o término. O cabeçalho final permitia medir, decidir o tipo de porção e então passar também a descrição pelo compressor.

Header-Last era, portanto, uma decisão sobre tempo e percurso de dados. Header-First podia ser negociado quando os quadros não eram divididos, quando a compressão não dependia de SDTP ou quando o hardware favorecia a ordem convencional. A negociação estabelecia uma interpretação comum. Não relatava taxa de compressão, estado interno do compressor nem sucesso da reconstrução.

A própria transmissão exigia estado prévio. PPP tinha de chegar à fase Network-Layer Protocol e SDCP ao estado Opened. A IANA registra 0x0049 para PPP-SDTP e 0x8049 para PPP-SDCP. Esses números e o estado negociado identificavam a sintaxe compartilhada. Não autenticavam o conteúdo de um pacote posterior nem comprovavam sua completude.

Sem opções, um campo Information do PPP continha um único pacote SDTP. Length só aparecia quando Length-Field-Present e a opção LCP Compound-Frames da RFC 1570 haviam sido negociadas. Vários pacotes podiam então ocupar o mesmo recipiente PPP. Cada valor Length incluía o próprio campo, Port opcional, cabeçalho de adaptação, dados e eventual Odd-Pad. Um octeto representava totais de 2 a 255; dois alcançavam 65535; zero significava todo o restante do campo Information.

Esse mecanismo respondia onde terminava uma unidade. Não respondia se o quadro serial original estava completo. Pacotes vizinhos em um quadro composto podiam pertencer a porções, quadros ou ports diferentes. Delimitar corretamente um recipiente não fornecia um aviso sobre um fragmento que nunca chegou.

Multi-Port acrescentava um espaço de nomes negociado. Sem ele, todo o tráfego usava o Port 0 implícito e o octeto não era transmitido. Depois da negociação, cada pacote carregava uma numeração: 0 a 254 para dados e 255 para controle. Algumas opções eram aplicadas por port, enquanto uma mensagem de controle de fluxo em 255 podia afetar todos.

Port era uma chave de demultiplexação, não uma identidade verificável. A RFC 1963 não ligava Port 7 por criptografia a um cabo, equipamento, cliente ou serviço. O significado dependia da tabela local mantida pelos participantes. Confirmar que essa tabela ainda representava a conexão física exigia outra evidência.

Os limites do quadro serial apareciam em B e F. No modo síncrono semelhante a HDLC, B marcava o começo e F a porção final; ambos desligados indicavam meio, ambos ligados indicavam um quadro inteiro. No modo assíncrono, ambos deviam estar ligados. E cumpria outra função: informava a presença da extensão de cabeçalho CS. Não era um bit de encerramento.

A distinção evita transferir campos de um protocolo vizinho. A RFC 1990 PPP Multilink usava B/E e um número de sequência de 12 ou 24 bits num conjunto de links. A RFC 1963 não usava esse formato. SDTP não possuía campo sequence e, por isso, não tinha uma regra Multilink para reconhecer lacunas pelo avanço de um contador.

A apresentação da RFC também contém uma razão para conferir texto e tabela. O quadro B/F imprime 1,0 para Begin Frame e repete 1,0 para Final Frame, embora a definição imediatamente acima diga que F assinala a porção final. A prosa e as definições ao redor sustentam a leitura B/F. Elas não revelam como um produto específico lidou com a repetição. Seriam necessários código, testes ou capturas para fazer essa afirmação.

O tratamento do FCS interno torna a fronteira de prova mais clara. Em quadros semelhantes a HDLC, SDTP transportava os bytes entre Flags, não as Flags. Por padrão, o FCS interno também seguia. Uma opção FCS-Type podia removê-lo no transmissor e regenerá-lo no receptor. A RFC 1963 alertava que isso não deveria ocorrer sem PPP Reliable Transmission ou outra camada que notificasse de forma confiável um pacote descartado. Também vedava entregar ao usuário um quadro incompleto ou ruim acompanhado de um FCS novo e correto.

B/F, Length e Port oferecem forma, extensão e classificação negociada. Nenhum oferece notícia de perda. Se um pacote intermediário desaparecesse sem sinal da camada inferior, o receptor poderia montar material com limites convincentes. Recalcular o checksum nesse ponto transformaria falta de evidência em aparência de integridade.

A RFC 1663 tratava outro problema com Numbered-Mode, janelas, confirmações e retransmissão. A RFC 1962 negociava algoritmos de compressão e trocas Reset. Essas funções não estavam escondidas nos campos SDTP. Header-Last coordenava a decisão de corte com o momento da compressão; não era o próprio compressor nem um sistema de entrega confiável.

A distinção proposta por Lu Heng entre estrutura declarada e evidência executável torna a arquitetura especialmente legível. A RFC 1963 declarava um mínimo comum: posições, extensões, limites, comprimentos e rótulos de port. Sistemas reais ainda precisavam demonstrar ordem de chegada, tratamento de perdas, política de buffer, vínculo local dos ports, tratamento do FCS e entrega à aplicação. O documento tornava as perguntas precisas, sem alegar que a execução já as havia respondido.

Fontes