Resumen

  • RFC 2127 asignó registros ifTable distintos a la interfaz física, las capas del canal D, cada canal B y la encapsulación superior; ifStack declaraba la relación local entre ellas, no un circuito comprobado de extremo a extremo.
  • Un hipercanal podía ocupar varios canales B y seguir siendo una sola llamada para las estadísticas de señalización. Las filas portadoras repetían sus datos, por lo que contarlas no revelaba ni llamadas ni capacidad útil entregada.
  • Desconectar significaba retirar el vínculo local de ifStack. Esa acción no certificaba por sí misma la liberación remota, el cierre del cobro o el resultado de la aplicación.

La contabilidad es donde la ambigüedad se vuelve costosa. Supongamos que una consola muestra tres canales B activos, con la misma dirección de par, la misma hora de conexión y las mismas unidades cobradas. ¿Son tres comunicaciones? En el caso decisivo de la RFC 2127, podían ser tres filas que describían una sola llamada multicanal.

El documento, publicado en marzo de 1997, no modeló ISDN como una luz de encendido. Una interfaz básica o primaria incluía soporte físico, un canal D para señalización, canales B para tráfico y una interfaz superior como PPP. En el canal D coexistían además LAPD y la entidad de capa de red. Cada capa recibía una fila conceptual propia y ifStack registraba su relación.

Una llamada no era una fila

Cada entrada de isdnBearerTable correspondía a un canal B. Su estado decía si ese puerto estaba libre, iniciando una llamada, validando una entrante o activo. Esa granularidad permitía administrar el recurso real: un canal podía fallar o quedar libre sin fingir que había desaparecido toda la interfaz física.

La RFC 1573 aportaba el modelo general de subcapas: una fila por interfaz conceptual y una tabla de pila para declarar cuál funcionaba encima de cuál. La RFC 2127 hizo visible esa topología para ISDN. Visible no significaba verificada fuera del equipo que la publicaba.

La RFC 2128 contenía la parte genérica del acceso bajo demanda: configuración de pares, llamadas activas e historial. Que la implementación de ese MIB fuera obligatoria marcaba una frontera sana. El puerto portador, el par configurado y el historial de la llamada podían relacionarse, pero no eran la misma autoridad.

El hipercanal cambió el denominador

Cuando una llamada pedía más de un canal B, había una interfaz de encapsulación encima de varios portadores. El implementador podía expresar el multiplexado mediante un DS0Bundle o mediante varias relaciones ifStack con el mismo índice superior y distintos índices inferiores.

RFC 2127 exigía que los portadores vinculados a esa llamada mostraran valores idénticos para dirección y subdirección del par, origen, tipo de información, multivelocidad, horas de establecimiento y conexión, y unidades cobradas. Esa repetición no creaba llamadas adicionales. La tabla de señalización sumaba una sola llamada, independientemente del número de canales B.

Por tanto, el recuento dependía de la pregunta. Para ocupación física interesaban los canales. Para señalización interesaba la llamada. Para rendimiento hacía falta medir el tráfico útil. Para facturación había que conocer la semántica de las unidades y la política comercial. Ninguna cifra sustituía a las otras.

La RFC 2494, publicada dos años después, formalizó los MIB de DS0 y DS0Bundle. Sirve como contexto posterior, no como inventario de lo que cada equipo de 1997 tenía instalado.

Colgar era borrar una relación

El texto especificaba la desconexión activa retirando la entrada ifStack que unía la interfaz de nivel superior con el canal B. Era una modificación administrativa concreta. Permitía registrar que el agente local aceptó dejar de mantener esa asociación.

Sin embargo, la operación no llevaba incorporada la prueba de todo lo que normalmente significa «la llamada terminó». El otro extremo podía requerir su propia liberación. La red podía tardar en cerrar señalización. El sistema de cobro podía conservar otro ciclo. La aplicación podía tener datos en cola o interpretar el corte de una forma distinta. La mutación local era necesaria para el modelo, pero su éxito no era un recibo universal.

Ceros y etiquetas que no cerraban la pregunta

La dirección del par pertenecía a la llamada actual o a la última. Su formato dependía a veces del conmutador o PBX, y podía quedar vacío. Almacenar una cadena no demostraba que estuviera normalizada, vigente o autenticada.

Las unidades cobradas también se referían a la conexión actual o anterior. En llamadas entrantes, o si el conmutador no entregaba información de cobro, el objeto valía cero. Ese cero era compatible con información ausente. No autorizaba a declarar que el servicio fue gratuito.

Los canales arrendados mostraban otra frontera. Un canal B de marcación tenía control por señalización asociada; uno arrendado no. Un acceso primario completamente arrendado podía administrarse con el MIB DS1/E1 sin información ISDN específica. La falta de una fila de señalización podía ser diseño, no avería.

Las capacidades de voz y audio tampoco describían por completo el tratamiento. RFC 2127 las llamó artificios de señalización y dejó a la red decidir cómo cumplir la calidad indicada. Una etiqueta de voz permitía tratamientos que podían impedir el funcionamiento de un módem. La etiqueta era una promesa acotada, no una descripción del trayecto.

Lo que el estándar no afirmó

El registro del RFC Editor y la ficha del IETF identifican un Proposed Standard del grupo ISDN MIB. El registro de erratas conserva una corrección técnica verificada del identificador de conformidad y otra propuesta rechazada. Nada de ello prueba adopción, calidad de implementación o precisión de una factura.

La sección de seguridad decía que el documento no trataba los problemas de seguridad. No ofrecía autenticación del gestor, confidencialidad de los objetos ni garantía contra cambios hostiles. Leer una protección en ese silencio sería inventarla.

El aporte histórico fue mostrar que un servicio podía necesitar varias identidades de gestión y que una identidad de gestión podía participar en más de una lectura del servicio. La disciplina posterior consiste en conservar el significado exacto de cada recibo.

Fuentes y límites

Los RFC sustentan mecanismos y semántica, no prevalencia de despliegue ni una llamada observada. Los ensayos posteriores de Lu Heng sobre la primacía del código en ejecución, la especificación inicial mínima y las capas de realidad se usan solo como disciplina interpretativa: especificación, estado local y resultado operativo requieren pruebas distintas. No son evidencia de la intención de los autores de 1997.