Resumen

  • Mediante PPPMuxCP, cada receptor podía ofrecer por separado su capacidad para aceptar tramas multiplexadas en una dirección. El acuerdo habilitaba el formato, pero no obligaba al par a transmitirlo.
  • El PID predeterminado era una regla para interpretar un identificador omitido. Solo un PFF realmente puesto a cero en una subtrama demostraba que el campo había desaparecido.
  • Agrupar paquetes reducía envoltorios, pero podía añadir espera y ampliar el efecto de un error o pérdida. Negociación, uso en el enlace, reconstrucción, medición y resultado de la aplicación son comprobantes distintos.

El problema aparecía cuando el envoltorio rivalizaba con el contenido

En una secuencia de paquetes pequeños, PPP puede gastar una proporción visible del enlace en repetir campos de encuadre. La compresión del campo de protocolo y la supresión de dirección y control reducen parte del coste, pero no eliminan cada bandera, identificador y secuencia de comprobación. Si además las tramas PPP viajan dentro de L2TP, cada unidad separada arrastra otra capa repetida.

RFC 3153 permitió colocar varios paquetes PPP como subtramas de una sola trama exterior. Cada subtrama recibe un delimitador compacto con una indicación sobre el PID y su longitud. La idea no comprimía los datos de la aplicación; repartía entre varios paquetes el coste de una envoltura común.

La ganancia requería coincidencia temporal. Si solo hay un paquete preparado, no existe un segundo encabezado que amortizar. Esperar a que llegue puede ahorrar bytes y aumentar demora al mismo tiempo. Por eso el RFC no presenta la multiplexación como un acelerador universal: identifica expresamente el intercambio entre menor sobrecarga y mayor latencia de agrupación y separación.

El dato histórico relevante no es que la fórmula permita ahorrar, sino cuándo el código decidió aplicarla. Para probarlo hacen falta las longitudes reales, el número de subtramas, los campos omitidos, el tiempo de cola y el resultado de la trama exterior.

La capacidad se anunciaba desde el lado que iba a recibir

PPPMuxCP se negocia durante la fase NCP. No es el emisor quien se concede a sí mismo permiso para agrupar: el receptor ofrece primero que puede interpretar ese formato. Sin la oferta, el par no puede enviarle una trama PPPMux.

La negociación es direccional. Que A acepte tramas de B no demuestra que B acepte tramas de A. Un registro que elimina la dirección puede convertir una capacidad unilateral en una afirmación bilateral falsa.

Incluso en la dirección correcta, el éxito solo abre una posibilidad. RFC 3153 dice que no obliga a transmitir tramas multiplexadas. El emisor elige cuáles paquetes agrupar y puede dejar pasar otros de forma autónoma.

Así, una consola que muestra «PPPMux: up» no responde a la pregunta operacional. Puede reflejar un Configure-Ack, una política preparada o tráfico realmente observado. La prueba une el diálogo de control con contadores y capturas del valor de datos 0x0059, en la misma dirección y con una cronología común.

El acuerdo sobre un PID no era la omisión del PID

La única opción de PPPMuxCP negocia un PID predeterminado. Lo propone el receptor: es el valor que usará para la primera subtrama cuando esta no incluya un campo de protocolo. Si el paquete coincide, el emisor puede poner PFF a cero y ahorrar uno o dos bytes.

Puede no hacerlo. El texto permite conservar el identificador aunque quitarlo sería válido. Por eso el valor acordado describe una semántica condicional, no una economía ya materializada.

Dentro de la trama, PFF también gobierna las subtramas posteriores. Un PID explícito actualiza Last_PID en el transmisor y Last_rcvd_PID en el receptor; un PFF nulo reutiliza ese estado. Antes de la primera actualización, ambos parten del PID predeterminado.

La consecuencia probatoria es clara. Para contar campos eliminados hay que recorrer las subtramas en orden. Ver una negociación, o incluso ver la trama exterior, no basta. Una implementación puede multiplexar sin omitir ningún PID; otra puede concentrar el ahorro en largas series del mismo protocolo.

Las dos formas de longitud daban precisión, no una política óptima

El delimitador combina PFF con LXT y LEN. LXT decide si la longitud usa un formato corto o extendido; LEN fija los bytes de la subtrama. El algoritmo ilustrativo añade MAX_SF_LEN para limitar qué paquete puede entrar y respeta el MRU negociado por LCP para el conjunto.

La construcción se detiene si el siguiente candidato es demasiado largo, si el agregado superaría el MRU o si ya no queda nada en la cola. Una implementación puede agregar un temporizador. El RFC advierte además que, por latencia y errores, conviene a veces limitar el conjunto muy por debajo del MRU.

Llenar hasta el techo no es, entonces, el comportamiento canónico. El MRU es un límite de recepción. MAX_SF_LEN es una selección local. El temporizador limita la espera. Ninguno de ellos, por separado, expresa el punto de equilibrio entre bytes, demora y riesgo.

Una trama más grande comparte mejor el encabezado, pero hace viajar juntos más resultados. Si se pierde o corrompe, varias subtramas quedan bajo el mismo fracaso exterior. El cálculo debe incluir la distribución real de tamaños, la tasa de error, el ritmo del enlace y la sensibilidad del tráfico.

Separar las subtramas exigía conservar la secuencia

Cuando llega 0x0059, el receptor lee las subtramas una tras otra. Usa PFF y su estado de PID para reponer lo ausente, y entrega cada paquete reconstruido al procesamiento PPP ordinario. Si la longitud declarada rebasa los datos que quedan, descarta la última subtrama. El error puede haber nacido en esa longitud o en una anterior que desplazó el análisis.

No se permite introducir una trama multiplexada dentro de otra, ni colocar tramas LCP como subtramas. Y el uso mixto no autoriza cambiar el orden: un paquete enviado solo no debe ser adelantado o retrasado arbitrariamente frente a sus vecinos agrupados.

Para comprobarlo, la captura debe conservar las tramas exteriores y el orden de entrega interior. Un total de paquetes reconstruidos puede ser correcto mientras oculta una inversión respecto de una trama autónoma.

La salida del demultiplexor tampoco es el final. El paquete todavía atraviesa otros protocolos, colas y aplicaciones. Que haya sido reconstruido solo demuestra el resultado de esa capa.

El lugar respecto de Multilink, compresión y cifrado era obligatorio

En un conjunto Multilink PPP, PPPMux se negocia para el bundle, no en cada enlace miembro. El transmisor multiplexa antes de aplicar MP, de modo que el encabezado Multilink queda por fuera. Una trama MP no puede aparecer como subtrama PPPMux.

La relación con CCP y ECP es igualmente concreta. El multiplexado ocurre después de las versiones a nivel bundle y antes de MP y de las versiones por enlace. Si una implementación no puede situar PPPMux por encima de un CCP o ECP por enlace, debe rechazar esa forma cuando PPPMux está negociado.

El orden determina qué representación comprime o cifra cada función. Dos equipos pueden enumerar las mismas capacidades y no interoperar si las ensamblan de otra manera. El lugar de la captura debe quedar anotado: antes de MP y sobre el enlace físico no se ven los mismos bytes.

La mera negociación de ECP no demuestra que una trama particular estuviera protegida. Igual que PPPMuxCP, el control necesita una prueba de ejecución.

La sección de seguridad no convirtió el formato en protección

RFC 3153 declara que no añade consideraciones de seguridad a las ya asociadas con PPP y la compresión de encabezados. La frase no promete autenticación, confidencialidad, integridad ni defensa frente a repetición.

Un desacuerdo sobre longitudes o estado de PID puede seguir causando fallos. Una trama bien analizada puede proceder de un par no autenticado. Un paquete recuperado puede activar una decisión insegura en otra capa. Nada de eso se resuelve porque el mecanismo no haya introducido una categoría nueva en 2001.

Las afirmaciones de seguridad deben unir autenticación PPP, estado real de ECP si existe, integridad observada, rechazo de entradas inválidas y efecto aguas abajo. Comprender la gramática no equivale a confiar en quien la usa.

El estándar fijó la compatibilidad y dejó abierta la decisión cotidiana

La fuerza de RFC 3153 reside en no convertir una optimización opcional en obediencia. El receptor podía limitar el formato que aceptaría. El emisor, una vez dentro de ese límite, conservaba la decisión sobre su cola. Las reglas comunes hacían determinista la reconstrucción; no intentaban centralizar la política de agrupación.

No usar la opción después de negociarla era compatible. Usarla antes de la oferta no. Esa frontera mínima permite que el cambio sea voluntario sin volver ambiguo el formato.

También organiza la evidencia. El Configure-Ack demuestra permiso. El 0x0059 demuestra una instancia de uso. PFF, LXT y LEN muestran la codificación. La salida del receptor demuestra reconstrucción. Solo una comparación temporal y de bytes muestra rendimiento. Solo la aplicación muestra su efecto.

La historia duradera de RFC 3153 no es «varios paquetes caben en uno». Es que una red puede acordar una capacidad sin falsificar su ejecución. El receptor ofrecía entender; el emisor aún debía decidir, y el enlace aún debía demostrar.

Fuentes