Resumo

  • LLC/SNAP acrescentava um identificador a cada AAL5 PDU e deixava vários protocolos dividirem um VC. Na multiplexação por VC, cada circuito levava um único protocolo e substituía a etiqueta explícita.
  • O segundo método economizava overhead por PDU, mas dependia de configuração de PVC ou negociação de SVC. A chegada de uma unidade AAL5 válida não provava o vínculo do circuito, o parser superior ou o resultado da aplicação.

Um VC compartilhado ou vários VCs especializados

RFC 1483 começou com uma decisão prática. Quando circuitos eram caros ou permanentes, LLC permitia colocar muitos protocolos em um só VC. Quando criar VCs era simples, cada protocolo podia ocupar o seu e evitar uma etiqueta multiprotocolo em todos os PDUs.

Na primeira opção, AA-AA-03, OUI e PID/EtherType diziam ao receptor o que vinha depois. Para IP, o exemplo usava OUI zero e 0x0800. Em tráfego em ponte, OUI/PID também indicavam a mídia original e a presença do FCS. O PDU carregava seu recibo de tipo.

Na multiplexação por VC, o payload não levava esse rótulo geral. O protocolo era inferido da conexão; vários protocolos exigiam várias conexões. A ficha do RFC 1483 registra os dois métodos, mas o efeito central era deslocar informação do pacote para uma relação operacional.

Um cabeçalho menor podia poupar processamento e até uma célula em certos tamanhos. Porém, alguém precisava manter a associação “este VC significa este protocolo”. No PVC, isso vinha da configuração nas duas pontas. No SVC, da sinalização da chamada.

A falha passou de um campo para uma corrente inteira

Um identificador LLC/SNAP inválido podia comprometer um PDU. Um vínculo errado de VC podia mandar uma sequência inteira de PDUs íntegros ao parser errado. O CRC de AAL5 verificava o envelope, não a semântica escolhida fora dele.

RFC 1755 especificou a negociação B-LLI para SVCs de IP sobre ATM. O originador oferecia encapsulações; o chamado escolhia uma suportada ou encerrava a chamada. A ficha oficial o define como guia de sinalização para interoperabilidade.

Mesmo assim, CONNECT só provava uma etapa do controle. Não provava PDU posterior, CRC, manutenção do vínculo, aceitação pelo IP nem resposta de aplicação.

O padrão default não era telemetria

RFC 2225 escolheu LLC/SNAP como default de Classical IP e ATMARP quando não houvesse outro acordo. A ficha do RFC 2225 situa essa regra na base estável do modelo.

O documento também separou o tipo de AAL: configurado nos PVCs e comunicado na abertura dos SVCs, sem aparecer no cabeçalho de cada célula. E limitou AAL5 a serviço não assegurado; detecção de erro e ordem não substituíam retransmissão superior.

RFC 2364 levou a mesma escolha ao PPP sobre AAL5. Chamou de implícito o tipo acertado por provisionamento ou controle no VC, e de explícito o tipo LLC dentro de cada PDU. Sua ficha mostra o contexto ponto a ponto. A autenticação PPP de uma sessão não protegia automaticamente os outros fluxos LLC no mesmo VC.

RFC 2684 preservou a troca e limitou a promessa

RFC 2684 substituiu RFC 1483 e manteve os dois métodos, esclarecendo ambiguidades de implementação. LLC tendia a usar menos VCs; multiplexação por VC tendia a usar menos bytes por PDU. A ficha do RFC 2684 registra a substituição, não a extinção comprovada de sistemas anteriores.

O texto ainda afirmou que encapsulação multiprotocolo era necessária, mas em geral insuficiente para rotear e fazer bridging sobre ATM. Formato, configuração, runtime, parser e resultado continuavam sendo camadas diferentes.

Fontes