Resumo

  • O RFC 3336 fez o CPS do AAL2 multiplexar, segmentar e remontar cargas PPP. Uma carga concluída podia sair sem esperar que uma unidade AAL5 grande fosse recomposta e desmultiplexada por inteiro.
  • No PPPMUX/AAL5, a falta de uma célula ATM podia invalidar todo o lote; no PPP/AAL2, o dano ficava nos pacotes presentes naquela célula. Ganhos de preenchimento e atraso dependiam de TIMER_CU, ritmo, tamanho, ocupação e implementação.

A economia de embalagem produzia uma dívida de espera

Tráfego de voz e acesso gerava muitas unidades pequenas. Encapsular cada uma separadamente em AAL5 desperdiçava capacidade com cabeçalhos e preenchimento. Reunir várias cargas PPP em uma unidade parecia resolver o problema: o custo fixo seria dividido.

Só que a unidade maior precisava chegar, ser remontada e validada antes de revelar seus componentes. No PPPMUX sobre AAL5, a multiplexação ocorria antes da segmentação do grande quadro em células ATM. Na recepção, a ordem se invertia; o quadro AAL5 inteiro era pré-requisito para ler o multiplexador.

O lote, portanto, era também um relógio. A carga curta concluída não podia avançar enquanto faltasse qualquer parte do recipiente. A otimização de largura de banda tinha criado um agrupamento de latência e integridade.

Uma célula ausente ampliava o prejuízo

Se uma célula ATM sumisse, a unidade AAL5 não passava pela remontagem ou verificação. Mesmo cargas completas alojadas em outras células daquele lote eram descartadas. A falta física afetava poucos bytes, mas a decisão protocolar atingia toda a coleção.

O AAL2 oferecia outra ordem. Seu Common Part Sublayer já misturava pequenos pacotes CPS em células, enquanto SSSAR cuidava dos fragmentos de cada pacote PPP. Assim, o receptor podia entregar uma carga assim que sua própria remontagem terminasse, sem depender de um recipiente coletivo maior.

O RFC não tornou a perda inofensiva. Uma célula podia levar fragmentos de vários pacotes e danificar todos eles. A mudança foi limitar o alcance aos ocupantes reais da célula, preservando cargas concluídas em outras. O domínio lógico se aproximava do incidente físico.

Os marcadores UUI separavam percurso e resultado

SSSAR usava o campo User-to-User Indication. O valor 27 identificava fragmento intermediário; 26, o último. Após remontar, o receptor verificava um CRC de 16 bits da carga PPP.

Esses fatos não podiam virar um único sinal de entrega. Um fragmento final podia aparecer depois de uma lacuna. Um CRC válido comprovava coerência naquele nível, não aceitação pela aplicação. Um evento connected podia levar LCP a Up sem demonstrar qualidade de voz ou atraso adequado.

Uma trilha útil separa mapeamento de CID, sequência UUI, sequência e paridade CPS, perda de célula, resultado SSSAR, CRC, TIMER_CU, estado LCP e resultado PPP final. O protocolo reduzia falha compartilhada; não emitia recibo de sucesso de ponta a ponta.

TIMER_CU impedia que eficiência significasse espera infinita

O CPS podia preencher uma célula ATM com vários pacotes curtos. Quando as chegadas eram próximas, sobrava menos espaço vazio do que em várias unidades AAL5. Porém, aguardar o próximo pacote indefinidamente destruiria a vantagem de atraso.

TIMER_CU encerrava essa espera. Quando expirava, a célula seguia com o conteúdo disponível e o espaço restante virava preenchimento. A eficiência variava com tamanhos, intervalos de chegada, carga, temporizador, escalonamento e equipamento. Fluxos densos e esparsos produziam resultados diferentes.

Também não era correto prometer “latência baixa” sem condição. O receptor não aguardava um quadro AAL5 grande, mas o transmissor podia aguardar a formação da célula. O mecanismo retirava uma espera obrigatória; não eliminava filas.

A relação de PPP ainda precisava de dois extremos

PPP supõe um enlace ponto a ponto, full-duplex. O RFC 3336 exigia uma conexão virtual AAL2 ponto a ponto, oferecida a PPP como enlace bit-síncrono. Os eventos connected e disconnected forneciam indicações de camada inferior ao LCP.

Capacidades multiponto de ATM não alteravam esse contrato. Um CID distinguia tráfego dentro da conexão, mas não transformava uma relação multiponto em um enlace PPP comum.

Uma sessão podia usar um ou mais CIDs. A extensão de várias classes, contudo, pertence ao RFC 3337. Importar sua semântica de prioridade para o RFC 3336 apagaria a separação entre o mapeamento básico e a melhoria posterior.

A família de documentos não substitui prova operacional

O RFC 1661 define PPP. O RFC 2364 descreve PPP sobre AAL5; o RFC 3153, PPPMUX; o RFC 2686, encapsulamento multiprotocolo sobre AAL5; e o RFC 2507, compressão de cabeçalhos IP. Eles mostram por que pequenas cargas tornavam overhead e preenchimento relevantes.

O RFC 3337 acrescentou classes. Mais tarde, o RFC 3985 organizou a arquitetura de pseudowire, e o RFC 4446 registrou alocações IANA. Essa sequência situa a ideia historicamente, mas não prova adoção por uma operadora, aceleração em hardware nem ganho medido.

O texto normativo prova intenção e comportamento especificado. Uma alegação de implantação requer versões, configurações, mapas de circuito, parâmetros, tráfego e medições. Possibilidade técnica não é estatística de mercado.

A inovação estava no lugar onde o destino passava a ser comum

O contraste não era apenas AAL5 contra AAL2. Era reconstituir antes de separar ou separar enquanto se reconstituía. No primeiro caso, a coleção precisava sobreviver para que seus membros existissem aos olhos do receptor. No segundo, cada membro concluído podia sair.

Uma única escolha de camada influenciava preenchimento, espera e amplificação de perda. O volume da vantagem dependia do tráfego, mas a causalidade era clara: deslocar a multiplexação mudava a unidade que esperava e falhava em conjunto.

O RFC 3336 deixa uma pergunta duradoura para qualquer rede: qual é o maior objeto que o receptor precisa julgar de uma vez? A engenharia não impede toda falta física. Ela decide quantos dados corretos serão sacrificados ao lado dela.

Fontes