Resumo

  • A RFC 2043 definiu dois Network Control Protocols SNA negociados de maneira separada: 0x804B controlava SNA sobre LLC 802.2 em 0x004B; 0x804D controlava NLPs HPR em 0x004D.
  • Opened autorizava o PPP a carregar o invólucro correspondente. Como não havia opções de configuração SNACP e a RFC não discutia segurança, o estado não provava o outro formato, recuperação, identidade, autorização, entrega, implantação ou êxito de uma sessão.

Um relatório de operação pode dizer “SNA aberto” e ainda estar errado por excesso. O fato verificável na RFC 2043 é menor: um NCP SNA específico alcançou o estado que permite enviar um tipo específico de pacote SNA pelo PPP.

Essa precisão é o objeto histórico do documento de outubro de 1996. Ele não oferece uma narrativa geral sobre PPP, IBM ou redes empresariais. Define como duas formas de SNA dividem um enlace ponto a ponto sem dividir a mesma máquina de estados.

A linha comum não eliminava as fases

A RFC 1661 organizou o PPP em uma sequência. LCP estabelece, configura e testa o enlace de dados. Autenticação, quando exigida, e determinação de qualidade precedem a fase dos protocolos de rede. Nessa fase, cada protocolo de camada de rede é configurado por seu próprio NCP.

LCP em Opened não abre automaticamente os protocolos transportados. Cada NCP pode abrir ou fechar em qualquer momento. Um pacote suportado que chegue antes de seu NCP correspondente estar aberto deve ser descartado silenciosamente.

A RFC 2043 mantém essa separação e afirma que existem, na realidade, dois NCPs SNA: um para SNA sobre LLC 802.2 e outro para SNA sem LLC 802.2. Eles são negociados separada e independentemente. O enlace é uma condição compartilhada, não uma ordem para igualar estados.

Quatro valores, duas relações de controle

No campo Protocol do PPP, valores da faixa inferior identificam pacotes de camada de rede, enquanto valores 8***–b*** identificam NCPs associados. A RFC 1700 já registrava os quatro valores; o registro atual da IANA continua a fazê-lo.

Na primeira relação, 0x804B identifica o protocolo de controle de SNA sobre LLC 802.2. Quando ele abre, 0x004B carrega exatamente uma PIU SNA XID ou FID2 com os campos DSAP, SSAP, Control e LLC Information.

Na segunda, 0x804D identifica o controle de SNA sem LLC. O valor de dados 0x004D carrega exatamente um Network Layer Packet HPR, com NHDR, THDR e dados.

Portanto, abrir 0x804B não diz que 0x804D abriu; observar 0x004D não informa o estado de 0x004B. Um indicador genérico de SNACP joga fora o vínculo entre controle e dados que permite localizar a falha.

A recuperação tinha um lugar, não um resultado presumido

No caminho 0x004B, LLC(2) foi incluído para recuperação de erros de enlace. A RFC 2043 atribuiu a execução dessa recuperação aos roteadores nas duas pontas do enlace PPP. É uma demarcação útil de responsabilidade.

Não é uma prova de sucesso. A presença de um pacote 0x004B mostra a forma utilizada no ponto observado. Ela não comprova retransmissão, chegada à outra ponta, aceitação da PIU, processamento do BIU ou continuidade da half-session SNA. Contadores e registros próprios precisam responder a essas perguntas.

O caminho 0x004D não contém LLC. Ainda assim, a RFC registra a possibilidade arquitetônica de transportar um NLP HPR pelo caminho LLC caso a implementação inclua a torre opcional de recuperação HPR. A opção pertence à implementação; não funde os dois NCPs e não transfere Opened de um para o outro.

Sem opções, não havia espaço para promessas adicionais

SNACP reutilizava a troca de LCP e empregava apenas os códigos 1 a 7, de Configure-Request a Code-Reject. Em seguida, a RFC 2043 declarava que não existiam Configuration Options para SNA nem para SNA sobre LLC 802.2.

Esse detalhe limita o valor semântico de um Configure-Ack. A troca pode habilitar uma família fixa de pacotes, mas não negocia identidade SNA, perfil de aplicação, meta de recuperação, rota, propriedade de segurança, autorização ou resultado comercial. Um ACK não pode confirmar o que nunca esteve no pedido.

Opened é um estado do protocolo de controle, não um laudo sobre o serviço.

Segurança e identidade continuavam fora do escopo

A seção Security Considerations informa que questões de segurança não são discutidas. O PPP podia executar autenticação antes da fase de rede, mas a RFC 1661 a deixava opcional por padrão. Quando usada, a evidência precisa identificar método, peer e resultado.

Um SNACP aberto não prova identidade, autorização dentro de SNA, sigilo ou integridade ponta a ponta. O limite de tamanho também não oferece essas garantias. A RFC 2043 prende o tamanho do pacote SNA ao campo Information do PPP; a RFC 1661 chama esse máximo de MRU e fixa 1500 octetos como padrão. A medida descreve o recipiente, não o destino do conteúdo.

Registro histórico não é telemetria de adoção

A RFC 2200 listou PPP-SNACP como Elective em 1997. A RFC 3790 observou depois que a especificação não dependia de IPv4. A IANA conserva as quatro atribuições. São evidências de classificação, arquitetura e identidade de registro, não de implantação.

Elas não demonstram produto compatível, teste entre implementações, volume de tráfego ou sessão empresarial. O fato de a busca atual do RFC Editor não apresentar errata descreve apenas o registro de correções.

Aplicada com cuidado, a leitura de Heng Lu mantém cada realidade em seu nível. A especificação estabeleceu uma regra comum pequena e verificável: reconhecer o invólucro, executar o NCP adequado e não transportar dados antes de Opened. Código, operação, recuperação e dependência real continuam exigindo outras observações. Publicar uma possibilidade de compatibilidade não cria seu uso.

O histórico confiável preserva quatro fatos: PPP chegou à fase de rede; um SNACP nomeado abriu; o valor de dados correspondente foi carregado; outra evidência mostrou o que ocorreu depois. Transformar os quatro em “sessão ativa” não simplifica a realidade — substitui evidência por um atalho.

Fontes