Resumen

  • LLC/SNAP permitía que varios protocolos compartieran un VC porque cada PDU llevaba su tipo. La multiplexación por VC quitaba esa etiqueta general y reservaba una conexión distinta para cada protocolo.
  • En un PVC, la interpretación dependía de la configuración administrativa previa; en un SVC, de la negociación durante la llamada. Reensamblar un PDU AAL5 no demostraba que esa relación, el analizador superior o la aplicación fueran correctos.

La configuración anterior al paquete también era protocolo

RFC 1483 describió en 1993 dos métodos para transportar PDU en AAL5. Con encapsulación LLC, una cabecera IEEE 802.2 y, cuando correspondía, SNAP identificaban el protocolo en los propios bytes. Para IP, la secuencia incluía LLC AA-AA-03, OUI cero y EtherType 0x0800. Un VC podía transportar varios protocolos porque cada PDU declaraba cuál era.

La multiplexación por VC eligió otra fuente de verdad. El payload no contenía un identificador multiprotocolo general. La conexión virtual indicaba implícitamente el protocolo y cada protocolo necesitaba su propio VC. La ficha del RFC 1483 resume la diferencia entre compartir un circuito y separar circuitos.

Para un PVC, el documento dejó la selección a la configuración manual. Antes de recibir tráfico, ambos extremos necesitaban la misma respuesta: LLC o VC multiplexado y, en el segundo caso, qué protocolo correspondía al circuito. El PDU podía llegar completo y aun así ser entregado al analizador equivocado si esa relación divergía.

Las tramas puenteadas mostraban otra capa. OUI y PID identificaban el medio original y la presencia del FCS. El CRC de AAL5 verificaba la envoltura externa, no proporcionaba por sí solo el significado de la trama interior.

Ahorrar cabecera trasladó el coste a una tabla

LLC repetía información en cada PDU y permitía usar menos VC. La multiplexación por VC ahorraba esos bytes y parte del procesamiento, pero exigía más circuitos y estado asociado. No eliminaba la etiqueta: la trasladaba a la relación entre el identificador del VC y una entrada de configuración.

La forma del fallo también cambiaba. Un campo LLC/SNAP erróneo podía afectar un PDU. Una asociación de circuito errónea podía interpretar mal toda una corriente de PDU válidos. Ninguna especificación demostraba que una instalación concreta mantuviera iguales las tablas de ambos extremos.

Para los SVC, RFC 1755 convirtió la elección en una negociación B-LLI. El llamante podía ofrecer métodos por preferencia; el llamado elegía uno compatible o liberaba la llamada. Su ficha oficial lo presenta como guía de señalización para interoperabilidad.

La negociación cerraba una ambigüedad de control, no la cadena de resultados. Una llamada establecida no probaba llegada posterior, CRC correcto, asociación vigente, aceptación de IP ni conclusión de una operación de usuario.

Un valor por defecto seguía siendo una regla

RFC 2225 convirtió LLC/SNAP en el formato predeterminado para Classical IP y ATMARP cuando no existía otro conocimiento o acuerdo. La ficha del RFC 2225 ubica esa decisión en una base estable de interoperabilidad.

El mismo texto explicó que el tipo AAL se configuraba en un PVC o se comunicaba al crear un SVC, y no viajaba en la cabecera de cada celda. También limitó la promesa de AAL5: orden y detección de errores en un VC, pero servicio no asegurado y retransmisión a cargo de capas superiores.

RFC 2364 aplicó ambos métodos a PPP. Distinguió el tipo implícito acordado por provisión/control del tipo explícito por PDU en LLC. La ficha del RFC 2364 enmarca esa elección en enlaces punto a punto con funciones PPP. Autenticar una sesión PPP tampoco aseguraba los otros flujos LLC del mismo VC.

La revisión posterior no convirtió encapsulación en red completa

RFC 2684 sustituyó RFC 1483 en 1999 y conservó sus dos métodos. Aclaró el intercambio entre menos VC y menor sobrecarga por PDU, y mantuvo la diferencia entre configuración de PVC y señalización de SVC. La ficha del RFC 2684 registra la sustitución normativa, no una retirada universal.

Su límite fue explícito: la encapsulación multiprotocolo era necesaria, pero por lo general insuficiente para enrutar o puentear sobre ATM. Saber cómo llamar al payload no probaba resolución de direcciones, ruta, autoridad, entrega ni efecto.

Fuentes