Resumen

  • RFC 3336 hizo que AAL2 CPS multiplexara, segmentara y reensamblara las cargas PPP. Un paquete completo podía salir sin esperar a que se reconstruyera primero una gran unidad AAL5 con muchos vecinos.
  • La ubicación reducía el fracaso compartido: PPPMUX/AAL5 podía perder todo el lote por una celda ausente; PPP/AAL2 limitaba el daño a los paquetes que ocupaban esa celda. El ahorro dependía de TIMER_CU, tamaños, ritmo de llegada, llenado e implementación.

La unidad de fallo se diseñaba antes de que ocurriera el fallo

Cuando muchas aplicaciones producen paquetes pequeños, envolver cada uno por separado resulta caro. Los encabezados y el relleno pueden ocupar una fracción desproporcionada de la capacidad. Multiplexar parece una respuesta obvia: juntar varias cargas útiles y pagar parte del envoltorio una sola vez.

Pero el lote no es gratis. Si las cargas se introducen en una unidad AAL5 grande, el receptor debe reconstruir esa unidad antes de leer el multiplexor que distingue a sus ocupantes. Los paquetes no solo comparten espacio; comparten el momento de liberación y el resultado de integridad del contenedor.

RFC 3336 trasladó la asociación a otro nivel. AAL2 CPS ya podía introducir paquetes cortos en celdas ATM y mantener sus límites mediante identificadores y fragmentos. PPP pasó a usar ese servicio: SSSAR formaba cada carga, mientras CPS realizaba la multiplexación. El paquete terminado recuperaba independencia frente al lote grande.

Una ausencia física podía amplificarse en una pérdida lógica

La comparación con PPPMUX sobre AAL5 explica el motivo mejor que una tabla de bytes. AAL5 reparte una unidad protocolaria entre varias celdas. Si falta una, el receptor no puede aceptar la unidad completa. Como el encabezado PPPMUX solo se interpreta después del reensamblado, las cargas intactas de otras celdas quedan atrapadas en el mismo rechazo.

PPP sobre AAL2 tampoco salvaba los datos que estaban dentro de la celda perdida. Una misma celda podía contener fragmentos de varios paquetes, de modo que el daño seguía siendo plural. La diferencia era su límite: los paquetes ya completados en otras celdas no dependían de la validación de un contenedor único.

Así aparece el “radio de pérdida”. Una avería física tiene un alcance inicial, pero el protocolo puede amplificarlo al decidir qué objetos deben validarse juntos. Cuanto mayor es la unidad indivisible, mayor puede ser la cantidad de información correcta que se descarta por solidaridad estructural.

UUI 27 y 26 marcaban el camino del paquete

SSSAR utilizaba el campo User-to-User Indication para describir fragmentos. El código 27 señalaba que faltaban partes; el 26 marcaba el fragmento final. Una vez reunida la carga PPP, un CRC de 16 bits comprobaba su integridad.

Ninguno de esos hechos equivalía a entrega completa. El final podía llegar después de una pérdida intermedia. El CRC podía ser correcto y, aun así, el protocolo superior podía rechazar el paquete. Un evento de conexión AAL2 podía llevar LCP a Up sin demostrar que el flujo de voz alcanzaba calidad útil.

Por eso conviene conservar recibos distintos: mapeo de CID, secuencia UUI, estado de secuencia y paridad CPS, indicación de celda perdida, reensamblado SSSAR, CRC, temporizador, transición LCP y resultado final PPP. Un contador único de éxito volvería invisible el mecanismo que se intenta verificar.

La eficiencia dependía de cuándo llegaba el siguiente paquete

AAL2 podía ocupar una celda con varios paquetes CPS pequeños. Si llegaban a tiempo, disminuía el hueco rellenado. Sin embargo, esperar indefinidamente para completar una celda añadiría una demora inaceptable. TIMER_CU ponía límite a esa espera: al expirar, se enviaba lo disponible y se rellenaba el resto.

La eficacia no era una propiedad fija del nombre AAL2. Dependía de tamaños, intervalos de llegada, carga, temporizador, planificación y hardware. Una ráfaga densa podía encajar bien; una fuente esporádica podía agotar el temporizador con espacio libre. Tampoco todo retardo desaparecía: se eliminaba la espera obligatoria por la gran trama AAL5, no la cola de formación de la celda.

La distinción evita convertir una especificación en publicidad. RFC 3336 explicó por qué una colocación podía funcionar mejor para paquetes cortos y sensibles al tiempo. No midió todos los equipos ni garantizó un porcentaje de ahorro en cualquier red.

El vínculo seguía siendo de dos extremos

PPP fue concebido para una relación punto a punto y dúplex completo. RFC 3336 exigió por ello una conexión virtual AAL2 punto a punto, presentada a PPP como enlace bit-síncrono. Los eventos de conexión y desconexión de AAL2 alimentaban a Link Control Protocol.

Que ATM pudiera representar otras relaciones no cambiaba la suposición de PPP. Un CID separaba canales dentro de la conexión, pero no convertía una topología multipunto en un enlace válido de dos extremos.

La sesión podía usar uno o varios CID. La semántica de clases múltiples, sin embargo, apareció en RFC 3337. Atribuir a RFC 3336 sus prioridades confundiría el mecanismo base con una extensión posterior y repetiría una historia distinta.

El vecindario documental no prueba despliegue

RFC 1661 es la base de PPP. RFC 2364 describe PPP sobre AAL5; RFC 3153, PPPMUX; RFC 2686, la encapsulación multiprotocolo sobre AAL5; y RFC 2507, compresión de cabeceras IP. Esos textos explican la presión por transportar eficientemente unidades pequeñas.

RFC 3337 amplió la propuesta con clases. RFC 3985 situó después la emulación de pseudowires en una arquitectura general, y RFC 4446 registró asignaciones IANA relacionadas. El encadenamiento histórico aclara interfaces y vocabulario, pero no demuestra que una operadora instalara RFC 3336 ni que obtuviera una mejora concreta.

Para afirmar adopción harían falta versiones de producto, configuraciones, mapas de circuito, tráfico real y mediciones. La norma demuestra intención y comportamiento especificado. La infraestructura vivida exige otra clase de prueba.

Multiplexar más abajo cambió quién compartía destino

El logro conceptual de RFC 3336 fue separar dos ventajas que a menudo se confunden. Se podía compartir el espacio de una celda sin convertir toda una colección grande en la unidad obligatoria de reensamblado. El multiplexor quedaba cerca de los fragmentos, y cada carga recuperaba su propio momento de conclusión.

La colocación afectaba a tres resultados: cuánto relleno se enviaba, cuánto esperaba una carga terminada y cuántas cargas correctas se perdían por una celda. Los tres seguían siendo variables, pero ya no estaban forzados por la misma trama grande.

La pregunta histórica útil no es si AAL2 era “más eficiente” en abstracto. Es qué decisión redujo el conjunto que esperaba y fallaba unido. RFC 3336 respondió moviendo la frontera donde el protocolo construía un destino común.

Fuentes