Articulo de referencia

Encapsulación multiprotocolo sobre ATM

La encapsulación multiprotocolo sobre ATM se especifica en el RFC 2684. Este define dos mecanismos para identificar el protocolo transportado en las tramas de la capa de adaptac...

La encapsulación multiprotocolo sobre ATM se especifica en el RFC 2684. Este define dos mecanismos para identificar el protocolo transportado en las tramas de la capa de adaptación ATM 5 (AAL5). Reemplaza al RFC 1483, un protocolo estándar de acceso al enlace de datos compatible con los módems DSL .

El RFC 2684 describe dos mecanismos de encapsulación para el tráfico de red: multiplexación de circuitos virtuales (VCM) y encapsulación LLC . Ambos mecanismos transmiten unidades de datos de protocolo enrutadas o conmutadas , y los módems DSL suelen incluir una configuración para la conmutación RFC 1483. Esto difiere de otros "modos de puente" comunes en módems y enrutadores DSL combinados , que desactivan la función de enrutador del módem DSL.

En la multiplexación de circuitos virtuales (VC-MUX), los hosts acuerdan el protocolo de alto nivel para un circuito determinado . Tiene la ventaja de no requerir información adicional en un paquete , lo que minimiza la sobrecarga. Por ejemplo, si los hosts acuerdan transferir IP , un remitente puede enviar cada datagrama directamente a AAL5 para su transmisión; no es necesario enviar nada más que el datagrama y el tráiler de AAL5. La principal desventaja de este esquema radica en la duplicación de circuitos virtuales : un host debe crear un circuito virtual separado para cada protocolo de alto nivel si se utiliza más de uno. Dado que la mayoría de los operadores cobran por cada circuito virtual, los clientes intentan evitar el uso de múltiples circuitos, ya que esto genera costos innecesarios.

En la encapsulación LLC, los hosts utilizan un único circuito virtual para múltiples protocolos. Esto tiene la ventaja de permitir que todo el tráfico circule por el mismo circuito, pero la desventaja de requerir que cada paquete contenga octetos que identifiquen el tipo de protocolo, lo que genera sobrecarga. Además, este esquema presenta la desventaja de que los paquetes de todos los protocolos viajan con la misma latencia y prioridad.

RFC 2684 especifica que los hosts pueden elegir entre dos métodos para usar AAL5. Tanto el emisor como el receptor deben acordar cómo se utilizará el circuito, y dicho acuerdo puede implicar una configuración manual. Además, los estándares sugieren que, cuando los hosts decidan incluir información de tipo en el paquete, utilicen una cabecera estándar IEEE 802.2 de Control de Enlace Lógico (LLC), seguida de una cabecera de Protocolo de Acceso a Subred (SNAP) si fuera necesario.

El tráiler AAL5 no incluye un campo de tipo . Por lo tanto, una trama AAL5 no es autoidentificable. Esto significa que los dos hosts en los extremos de un circuito virtual deben acordar de antemano que el circuito se utilizará para un protocolo específico (por ejemplo, que el circuito solo se utilizará para enviar datagramas IP), o bien deben acordar de antemano que algunos octetos del área de datos se reservarán para usarse como un campo de tipo que permita distinguir los paquetes que contienen datos de un protocolo de los paquetes que contienen datos de otro protocolo.

Véase también

  • Foro de cajeros automáticos
  • Comprensión de la interconexión entre IPoEoATM y RFC 1483
  • Sistemas Cisco