Resumen

  • BACP elegía qué par prevalecía en una carrera; BAP exigía respuesta antes de actuar; Call-Status informaba más tarde del intento real.
  • Un Ack sólo acreditaba una orden válida y recibida. No acreditaba enlace, tráfico ni rendimiento, y el datagrama BAP completo debía permanecer sin cifrar ni comprimir para ciertos adaptadores ISDN.

RFC 2125 empieza con un problema de coordinación, no de velocidad. Dos extremos podían observar el mismo haz PPP y decidir al mismo tiempo que debía cambiar. Si ambos llamaban o ambos retiraban una línea, una optimización local podía convertirse en carrera.

RFC 1990 ya había definido cómo varios enlaces formaban un haz Multilink. RFC 2125 añadió en 1997 dos protocolos para controlar sus miembros. Su ficha oficial registra el estándar y el registro PPP de IANA mantiene los valores de BACP y BAP.

El número menor sólo deshacía el empate

La opción obligatoria Favored-Peer negociaba dos Magic-Number no nulos. Cuando ambos extremos enviaban simultáneamente una solicitud equivalente, prevalecía el número menor. Un empate provocaba una nueva negociación.

Ese resultado no identificaba al operador ni decidía quién tenía razón sobre la carga. Era un desempate reproducible para una operación simultánea. Confundirlo con autoridad ampliaría el hecho más allá de lo que el paquete contenía.

Aceptar la orden no hacía sonar el teléfono

Call-Request pedía permiso para originar otro enlace. Callback-Request pedía al par que lo originara. Toda solicitud o indicación requería respuesta antes de actuar. Request-Ack confirmaba una orden válida y recibida; Request-Nak aplazaba; Request-Rej señalaba falta de soporte; Request-Full-Nak informaba que el haz ya estaba en el máximo o mínimo disponible.

El resultado del intento llegaba después en Call-Status-Indication. Cada llamada producía una indicación. Un fallo decía si habría reintento, y cada reintento exigía su propio resultado. El identificador de la solicitud original enlazaba ambas fases sin convertirlas en la misma fase.

Así se formaba una escalera: BACP abierto; ganador de la carrera; solicitud admitida; llamada completada; alta o baja mediante LCP; fragmentos Multilink vistos; operación de aplicación concluida. Un peldaño no sustituía a los siguientes.

La utilización pedía acuerdo; el puerto físico podía imponer la salida

RFC 2125 evitó imponer un algoritmo común de ancho de banda. Cada extremo podía vigilar transmisión, ambas direcciones o ninguna. Si la retirada nacía de esa medición, debía usar Link-Drop-Query: el otro lado podía negarse y el enlace seguía activo mientras alguno de los monitores lo necesitara.

Una necesidad local de recursos tenía otro peso. Si hacía falta el puerto o canal B, la implementación enviaba directamente Terminate-Request de LCP. También podía hacerlo tras agotar los reintentos esperando respuesta a una consulta de retirada. El diseño distinguía negociación de eficiencia y custodia inmediata del recurso.

Las retransmisiones repetían el mismo identificador, para que perder una respuesta no fabricara una operación nueva. BAP debía recibir prioridad sobre datos ordinarios: la señal que añadía capacidad no podía quedar indefinidamente detrás de la congestión que intentaba aliviar.

Una concesión a la interceptación

Algunos adaptadores ISDN administraban Multilink delante de clientes que no lo entendían. Por eso el datagrama BAP completo no podía comprimirse ni cifrarse. La compresión negociada de ciertos campos PPP seguía permitida, pero el mensaje de control debía ser visible al adaptador. La sección de seguridad del RFC decía que no trataba cuestiones de seguridad.

No hay base para convertir estas señales en confidencialidad, identidad, consentimiento o éxito de negocio. Los ensayos de Lu Heng sobre primacía del código operativo, especificación inicial mínima y capas de realidad aportan una lente moderna declarada: estandarizar el mínimo común, mantener local la heurística y no hacer pasar permiso simbólico por resultado ejecutado.

Fuentes