Resumen

  • El identificador de la parte llamada podía escoger PPP entre varios servicios de un mismo acceso ISDN, pero no autorizaba al extremo a ponerlo en funcionamiento.
  • RFC 1618 ordenaba rechazar la llamada si faltaba el evento administrativo Open; aceptar el circuito para cerrarlo después o ignorar sus paquetes estaba prohibido.
  • Aceptar solo iniciaba otra cadena: codificación, trama, Up físico, LCP Opened, autenticación, NCP y resultado de la aplicación necesitaban pruebas propias.

Una puerta correcta que seguía cerrada

RFC 1618, publicado en mayo de 1994, llevó PPP a circuitos conmutados ISDN. El propio documento advertía que no habría un único ISDN monolítico mundial. Había diversidad de centrales, equipos terminales y políticas de suscripción; la norma escogió unos puntos comunes para favorecer interoperabilidad, no una descripción universal de toda red.

El canal B ofrecía un circuito punto a punto adecuado para PPP. Una interfaz PRI podía sostener muchos canales B simultáneos. El canal D también podía transportar paquetes PPP con la trama apropiada, aunque tenía menos ancho de banda y a menudo no salía de la central local. Esas capacidades decían qué transporte estaba disponible. No decidían qué servicio debía aceptar una llamada.

Varios números de directorio podían terminar en la misma instalación física. Un administrador asociaba cada número con un servicio, y la central local entregaba el identificador de la parte llamada. Así, una sola línea física podía tener varias puertas lógicas. El número permitía escoger la puerta; no demostraba la identidad del visitante ni transfería el permiso para abrirla.

El campo más rico era el menos fiable

El LLC Information Element parecía ofrecer una solución más elegante. Al viajar en la señalización fuera de banda, podría haber indicado qué codificación o trama esperaba la llamada antes de intercambiar paquetes. La experiencia recogida por RFC 1618 mostró que no era una base segura: pocos conmutadores compatibles lo transportaban de extremo a extremo y las políticas de los proveedores diferían demasiado.

En 1994 no había un valor LLC-IE asignado a PPP. Cualquier otro valor recibido no era válido para un enlace PPP y podía ignorarse. La norma también dijo que el elemento no debía usarse para decidir codificación o trama.

El problema no era solo pérdida de bits. El campo cruzaba instituciones con distintas reglas de abono. Un dato común deja de ser común cuando un intermediario puede omitirlo o reinterpretar su alcance. RFC 1618 no convirtió esa fragilidad en falsa autoridad; prefirió una señal local más limitada y mantuvo la decisión final en el receptor.

Open no venía de la central

La regla de admisión era tajante. Si se usaba el identificador de parte llamada —o si en el futuro llegaba un LLC-IE asignado a PPP— y LCP no había recibido su evento administrativo Open, la llamada tenía que rechazarse. El receptor no podía aceptar y luego cerrar el circuito, ni aceptar y dejar los paquetes sin respuesta.

En RFC 1548 y después en RFC 1661, Open expresa que un administrador de red, humano o programa, permite abrir el enlace. No es el evento Up, emitido cuando la capa inferior está disponible. Tampoco es el estado Opened, alcanzado por el autómata tras negociar configuración con el par.

La similitud de los nombres puede esconder tres dueños. La central ofrece el circuito. La política local autoriza el servicio. Los dos extremos negocian la configuración. Que el primero haya actuado no obliga al segundo ni prueba el tercero.

Rechazar pronto hacía visible un “no” que ya existía. Si el receptor aceptaba primero, ocupaba un canal conmutado y luego transformaba una decisión administrativa en un síntoma tardío. Desde fuera, el silencio podía parecer un error de trama, un equipo averiado o pérdida de red. La negativa en la frontera correcta evitaba ese traslado de responsabilidad.

La autodetección era una serie de ensayos

Tras la admisión quedaba por averiguar cómo representar los bits. Para PPP, el canal ISDN era un enlace síncrono de dúplex completo, pero RFC 1618 dejaba la codificación y la aleatorización bajo responsabilidad del equipo DTE/DCE. Recomendaba NRZ como valor inicial en el punto T, NRZI como alternativa configurada y desaprobaba el NRZ invertido usado por algunos sistemas anteriores.

Un equipo que quisiera reconocer varias codificaciones simples debía rotar entre modos. En cada uno enviaba dos LCP Configure-Request y dejaba tiempo para una respuesta antes de cambiar. La suma total no podía superar 59 segundos; la ventana habitual de 30 segundos era preferible.

No había un oráculo de codificación. Había pruebas con presupuesto. El silencio de un modo solo justificaba avanzar al siguiente; no identificaba por sí mismo al culpable. El límite temporal protegía canales, dinero y capacidad de atención frente a una búsqueda que, sin freno, podía durar tanto como hubiera tráfico esperando.

La trama también empezaba con una elección explícita. Sin configuración previa, el canal B debía comenzar con HDLC síncrono a bits. El modo síncrono a octetos se recomendaba cuando los límites de octeto estaban disponibles y se habían configurado. Aunque HDLC, LAPB, LAPD y LAPF tuvieran rasgos distintos, RFC 1618 desaconsejaba ejecutar varias tramas simultáneamente en un canal.

Para este uso, el documento declaró obsoleto V.120 porque su trama podía confundirse con Frame Relay, y recomendó transportar PPP dentro de Frame Relay. Era una preferencia de interoperabilidad, no una prueba de que alguno de los dos métodos se hubiera usado en una llamada concreta.

RFC 1549 añadía una consecuencia: NRZI reducía ciertas propiedades del FCS de 16 bits, por lo que recomendaba negociar un FCS de 32 bits. Un portador presente no garantizaba el mismo criterio de integridad en ambos lados.

Una cola podía fabricar llamadas

RFC 1618 recomendó una MTU de capa de red no superior a 1500, salvo que se negociara expresamente con el par una MRU de al menos 2048. Para los reinicios, recomendó retroceso exponencial desde 250 milisegundos hasta tres segundos. La marcación persistente y la remarcación debían tener límites. Si no se completaba el establecimiento, descartar la cola de transmisión podía retirar temporalmente el paquete que provocaba nuevas llamadas.

Esa cola era parte del sistema de control. Un paquete pendiente originaba la llamada; el fallo lo dejaba esperando; su presencia originaba otra. Sin un límite, una petición de aplicación podía consumir una secuencia de circuitos. Sin registrar el descarte, la solución también podía borrar la única pista sobre lo que inició el ciclo.

El RFC prefirió PPP Multilink a BONDING, cuya inicialización interfería con la detección sencilla y podía exigir mucha configuración por canal. RFC 1990 formalizó después Multilink para combinar canales ISDN y otros enlaces de capacidad bajo demanda. Incluso entonces la agrupación dependía de una opción LCP negociada: dos canales físicos no declaraban por sí solos un único enlace lógico.

Después de aceptar todavía faltaba el servicio

La secuencia completa continuaba. Había que acertar codificación y trama, observar Up, negociar LCP hasta Opened, completar la autenticación si se había elegido y abrir el NCP del protocolo de red. Solo después podían circular sus datagramas. Y transportar un datagrama aún no probaba que la aplicación hubiera hecho algo útil.

El registro del RFC Editor acredita fecha, autoría y la etiqueta actual Proposed Standard. No acredita despliegues, productos ni práctica actual. RFC 1618 tampoco analiza seguridad; el número llamado no debe convertirse en autenticación del llamante.

La primacía del código en ejecución de Heng Lu ofrece la disciplina interpretativa: el campo y la configuración son declaraciones; la decisión efectiva y el resultado observado son capas distintas. Su especificación inicial mínima ayuda a entender por qué los defaults podían compartirse y la admisión seguir siendo local.

La central indicaba qué servicio se había llamado. El extremo conservaba la autoridad para decir que ese servicio no estaba abierto. RFC 1618 quiso que esa negativa ocurriera antes de que un circuito aceptado confundiera política con avería.

Fuentes