Resumen

  • Los fragmentos enviados por varios miembros usaban una secuencia para todo el haz. B y E delimitaban el paquete, y el número avanzaba por fragmento sin reiniciarse al comenzar otro paquete o incorporarse una línea.
  • El acuerdo no obligaba a dividir por igual ni imponía un planificador. Un paquete pequeño podía quedar entero; MRRU marcaba el máximo que el receptor se comprometía a reconstruir.
  • El FCS de cada enlace protegía su fragmento, no el paquete recompuesto. Endpoint Discriminator ayudaba a agrupar sin autenticar, y BAP/BACP y la extensión multiclase separaron después las decisiones de ancho de banda y latencia.

Una línea más no creó otra sesión de red

Supongamos que un primer canal PPP ya transporta tráfico y un segundo acaba de abrirse. Si cada canal se presenta como enlace independiente, aumentar capacidad también duplica direcciones, negociación de protocolos de red y estado operativo. Si se reparten bytes sin una regla común, las diferencias de velocidad dejan al receptor ante piezas adelantadas y retrasadas que no sabe ordenar.

Multilink introdujo el haz como objeto intermedio. Cada miembro conservaba su framing, LCP y autenticación. Los protocolos de capa de red se negociaban normalmente una vez para el conjunto. Un miembro podía entrar o salir sin destruir por ello toda la conversación superior.

RFC 1717 presentó la idea en 1994, con varios canales B de ISDN como motivación visible. RFC 1990 lo sustituyó en 1996 y endureció la semántica. Hablar solo de sumar caudales oculta la innovación: el protocolo decidió qué estado mínimo debía sobrevivir cuando la composición física cambiaba.

Primero existía el paquete lógico

El emisor tomaba un paquete de protocolo de red y le añadía su campo Protocol de PPP. Todavía no incorporaba Address, Control, Flags ni FCS de una línea concreta. Ese paquete encapsulado, no una trama física terminada, era el objeto que podía dividirse.

Cada pieza se enviaba como protocolo PPP 0x003d con un encabezado MP. La primera empezaba por el Protocol del paquete original. El bit B marcaba el inicio y E el final. Ambos podían valer uno si un solo fragmento contenía todo el paquete.

Multilink no exigía partir siempre. Los paquetes pequeños podían cruzar enteros y las piezas de los grandes no tenían que medir lo mismo. El planificador podía asignar más bytes a una línea rápida, alternar miembros o aplicar otra política local. Nada de eso alteraba la gramática que debía entender el receptor.

La frontera era deliberada: el estándar compartía identidad de fragmento, límites de paquete y secuencia, no el razonamiento interno de cada planificador.

La secuencia no se reiniciaba con el paquete

El encabezado ordinario llevaba 24 bits de secuencia. Los extremos podían negociar 12 bits para ahorrar encabezado, pero todo el haz debía usar un formato único. Cada fragmento consumía el siguiente número.

Al terminar un paquete, el contador seguía. Al incorporarse un segundo miembro, también seguía. Solo un haz nuevo empezaba en cero. Así, el primer fragmento de una línea recién añadida no podía confundirse fácilmente con una pieza vieja demorada en otra.

El receptor mantenía una reconstrucción común para el haz. Como los miembros podían tener velocidades y retrasos diferentes, la llegada desordenada era normal. Se observaba cuánto había avanzado la secuencia en cada miembro y se calculaba el mínimo que todos habían superado. Si un número anterior seguía ausente, ya no podía justificarse solo como pieza pendiente en la línea lenta; el paquete incompleto podía descartarse para recuperar la sincronía.

La memoria no eliminaba toda incertidumbre. Su tamaño dependía de retrasos, caudales y fragmentos máximos. RFC 1990 advertía que ninguna cantidad de buffer garantizaba detectar a un par que retuviera paquetes. La secuencia hacía posible una decisión acotada, no una garantía de fiabilidad.

Once comprobaciones limpias no reconstruían una pieza perdida

Cada miembro encerraba el fragmento MP en una trama PPP y aplicaba su propio FCS. Un FCS correcto respaldaba ese fragmento en ese enlace. No había otro FCS sobre el paquete completo después de reunirlo.

Diez piezas pueden pasar todas sus comprobaciones y una undécima no llegar. El paquete no existe para la capa superior. Por eso “sin errores FCS” no equivale a “entrega completa del haz”.

MP tampoco impuso un detector único de enlace fallido. LQM o LCP Echo podían aportar señales, pero eran mecanismos separados. La entrega fiable por miembro exigía negociar PPP Reliable Transmission aparte. Multilink ordenaba y recomponía; no retransmitía ni confirmaba la transacción de una aplicación.

Un diagnóstico sólido separa estado de cada miembro, errores de trama y FCS, último número visto, mínimo del haz, huecos, descartes incompletos, paquetes completos entregados y resultado superior. Un único estado verde mezcla control, transporte y entrega hasta volverlos indemostrables.

MRRU limitaba la promesa del receptor

Maximum Reconstructed Receive Unit era el máximo campo de información recompuesto que aceptaría el receptor del haz. No era el MRU de cada miembro. Una línea solo necesitaba alojar su fragmento; el paquete lógico podía ser mayor dentro del MRRU acordado.

La opción LCP MRRU tenía tipo 17 y señalaba de forma explícita la capacidad Multilink. RFC 1990 exigía al menos 1500 octetos y eliminó un supuesto valor por defecto. Short Sequence Header Format era el tipo 18.

Endpoint Discriminator, tipo 19, ofrecía una pista para decidir si dos líneas llegaban al mismo par y debían compartir haz. No anunciaba por sí solo capacidad MP ni autenticaba a nadie. Algunas clases eran locales, sin unicidad global. Magic-Number Block era como mucho probablemente único y se desaconsejó como clave de base de datos o autenticación cuando había métodos reales.

El valor podía falsificarse. Para admitir de forma segura un miembro, el RFC remitía a la autenticación PPP. Un identificador ayuda a relacionar; no concede autoridad.

Llamar a otra línea era otra decisión

El MP básico aceptaba miembros dinámicos, pero no fijaba cuándo realizar otra llamada ni qué extremo controlaba esa decisión. RFC 2125 asignó esas funciones a BACP y BAP. BACP escogía el par con control de asignación; BAP solicitaba altas o bajas y comunicaba el resultado de la llamada.

Que una llamada terminara bien demostraba ese paso de control. No probaba que el nuevo miembro tuviera la configuración prevista, llevara fragmentos, aumentara caudal o entregara una operación de usuario.

La prioridad recibió asimismo otra extensión. RFC 2686 mostró que 1500 bytes en 28,8 kbit/s podían ocupar unos 400 milisegundos y acercar a un segundo el recorrido de una conversación. Varias clases permitieron intercalar tráfico urgente entre fragmentos menos prioritarios. La secuencia base solucionaba reconstrucción, no toda política de latencia.

El haz fue un acuerdo mínimo

Los pares compartían capacidad MP, MRRU, un formato de secuencia, límites B/E y un espacio de números. El tamaño de fragmento, la línea elegida, la detección de fallos, las llamadas y la prioridad permanecían locales o en protocolos opcionales.

El haz no borraba la realidad de sus miembros ni constituía un controlador central. Era la porción común necesaria para que implementaciones con decisiones distintas reconstruyeran el mismo paquete.

La evidencia debe seguir esa escala. 0x003d prueba una representación MP en el punto observado; B/E y el número describen la posición declarada; MRRU prueba un límite negociado; el discriminador da una pista. Entrega, identidad, ganancia de capacidad y uso actual solo se cierran con capturas, contadores por miembro, reconstrucciones completas y resultados de la capa superior.

Fuentes