Características principales de ATM e IP

La diferencia crucial entre los protocolos ATM e IP es que ATM está

orientado a la conexión mientras que el IP no tiene conexión. Esto significa
que el establecimiento de una conexión entre dos puntos finales en ATM
define la ruta que deben recorrer todas las células relacionadas con esa
conexión. Cada celda de datos que atraviesa la ruta tiene una dirección
específica para el enlace en el que se encuentra actualmente, y esta dirección
no es única a nivel mundial. Por lo tanto, si la ruta se rompe, se debe
establecer una nueva conexión antes de que se pueda reanudar la transferencia
de datos. Por otro lado, IP no tiene conexión. Cada paquete IP lleva una
dirección de destino completa y no existe un concepto de conexión en el nivel
de IP. Como consecuencia, no hay ninguna razón para que los datagramas IP
consecutivos necesiten atravesar una red por la misma ruta, siempre que
lleguen al destino requerido.

Si los datagramas IP consecutivos viajan por rutas diferentes, pueden llegar a

su destino en un orden diferente al orden en que se transmitieron. Por lo tanto,
IP no puede garantizar el orden, y las capas más altas pueden necesitar
reordenar los paquetes a medida que llegan. Por el contrario, como las células
en una conexión determinada viajan por la misma ruta, no hay ninguna razón
para que lleguen fuera de orden, y por lo tanto ATM garantiza que las células,
si llegan, llegarán en orden.

Es importante entender que ambos protocolos son solo servicios de mejor

esfuerzo, aunque ATM asume que los enlaces son altamente confiables y
tienen tasas muy bajas de pérdida celular y corrupción celular, mientras que IP
no lo asume. Tanto en ATM como en IP, la provisión para la recuperación de
errores y la retransmisión son responsabilidad de las capas superiores.

Modelado de tráfico solo IP

Para modelar el tráfico IP en ATM _ TN requiere la adición de enrutador IP, IP
extremo-nodo y componentes de enlace de IP para el modelo. Idealmente, uno
querría construir el componente del enrutador para modelar el enrutamiento
dinámico, pero decidí que el enrutamiento estático sería adecuado.

Las clases de eventos deben modificarse para enviar datagramas IP en lugar

de celdas ATM entre componentes.

Los modelos de tráfico conectados a los nodos finales deben modificarse

sustancialmente ya que deben generar paquetes IP en lugar de celdas ATM. Es
desafortunado que los modelos de tráfico existentes generen células ATM, si
se hubieran diseñado para generar PDU AAL, con el modelo de red que
genera celdas ATM de las PDU AAL en los nodos finales, entonces las
modificaciones requeridas serían menores.

Finalmente, la ubicación donde se recopilan las estadísticas debe ser

alterada. La información estadística debe recopilarse en la capa en la que se
produce el enrutamiento o el cambio. ATM realiza la conmutación en la capa
de enlace, mientras que el enrutamiento IP ocurre en la capa de red. En
consecuencia, las funciones estadísticas en los nodos finales y los enrutadores
deben desplazarse desde la entrada LP a la red LP.

Por qué llevar un cajero automático a

través de una red IP?
ATM se concibió inicialmente como una tecnología de conmutación basada
en células y de propósito general para todo el tráfico orientado a la conexión y
sin conexión. Otros protocolos se llevarían a través de ATM y, por lo tanto,
ATM podría considerarse como una sustitución de `bits en un cable 'por`
células en un cable' como una tecnología de transmisión.

Sin embargo, ATM no ha logrado la penetración global que sus diseñadores

esperaban, y dentro del mundo de las redes comerciales se está considerando
pasar por alto la capa ATM en fibra y ejecutar IP sobre fibra dentro de marcos
SONET [ 4 ], o incluso IP directamente sobre fibra.

Si tales ideas llegan a buen término a gran escala, es posible que finalmente
lleguemos a una situación en la que partes de la red global de cajeros
automáticos se aíslen unas de otras por segmentos de IP. Bajo estas
circunstancias, el único método por el cual las aplicaciones que usan ATM
como su protocolo de transmisión podrían comunicarse a través de estos
segmentos requeriría un protocolo para transportar las células ATM a través
de la red IP.

Otra razón para investigar esto es la posibilidad de que las redes de

datagramas sin conexión puedan ser más eficientes que las redes de células
orientadas a conexiones de circuitos virtuales.

Hacer que una red IP incrustada sea

invisible para el cajero automático
Considere una gran red de cajeros automáticos dentro de la cual una parte ha
sido convertida para operar como una red IP. Tanto las aplicaciones que usan
ATM como su protocolo de transporte y las capas AAL en los nodos finales
no deberían poder determinar si las celdas ATM que atraviesan la red han
viajado a través de un enlace IP en la ruta. Idealmente, incluso la lógica de
control ATM no debería poder determinar esto.

Hay dos formas de ocultar una red IP dentro de una red de cajeros
automáticos:

1. hacer que la red IP aparezca como un enlace ATM al resto de cajeros

automáticos.
2. hacer que la red IP aparezca como un conmutador ATM para el resto
de cajeros automáticos.

Veré las ventajas y desventajas de cada uno a su vez:

La red IP como un enlace ATM emulado

Esto es el equivalente a hacer un túnel IP entre los puntos de la red

ATM [ 9 ]. Si bien este enfoque es técnicamente más fácil que la
segunda opción si la red IP consiste en un solo túnel entre dos puntos
de conexión, tiene limitaciones severas de escala. Cada punto de
conexión entre la red IP y la red ATM requiere un túnel lógico
separado para cada otro punto de conexión. Para agregar un punto de
conexión requiere nuevos túneles lógicos, y en una red con
puntos de conexión, la cantidad total de túneles lógicos requeridos

es . Por lo tanto, agregar un nuevo punto de conexión a una

red IP con una cantidad sustancial de puntos de conexión existentes
será un ejercicio importante.

La red IP como un conmutador ATM emulado

Esta alternativa parece menos atractiva al principio, pero escala con

mayor facilidad. La conmutación de ATM está limitada solo por el
tamaño de los campos VP y VC en el encabezado ATM. La
conmutación UNI utiliza un campo VP de 8 bits y un campo VC de 16
bits; La conmutación NNI usa un campo VP de 12 bits y un campo VC
de 16 bits.

Una conexión cruzada UNI por lo tanto, puede tener hasta 256
conexiones; una conexión cruzada NNI, hasta 4096. Un interruptor
UNI puede tener hasta 16 millones de conexiones; un interruptor
NNI, hasta 256M. Como un interruptor, la cantidad de puntos de
conexión entre la red ATM y la red IP es virtualmente ilimitada.
Al comparar estos dos métodos para ocultar redes IP dentro de ATM, uno
queda impresionado por la similitud entre esto y el uso de circuitos virtuales
permanentes versus conmutados (PVC contra SVC) en ATM.

Hacer túneles de IP para ATM es similar en algunos aspectos a la creación de

PVC en redes de cajeros automáticos. Los túneles IP, como los PVC, están
codificados de forma rígida y deben crearse (y destruirse) estáticamente. Los
protocolos necesarios para mantener los túneles de IP son relativamente
simples, pero carecen de flexibilidad.

Hacer que la red IP parezca emular un conmutador ATM es similar en algunos

aspectos a la creación de SVC en redes ATM. Los SVC permiten que las
conexiones se creen y destruyan dinámicamente según sea necesario. Por lo
tanto, son más versátiles, pero los protocolos para crearlos, mantenerlos y
finalmente destruirlos son necesariamente más complejos.

En las extensiones a ATM _ TN que he diseñado, la segunda alternativa, la red

IP como un conmutador ATM emulado, se implementa.

Emulación de funciones de control del

interruptor en una red IP
Todos los conmutadores ATM tienen una capa de red que contiene la lógica
de control para ese conmutador. Una instancia de red IP, que debe aparecer en
la red ATM como un conmutador ATM, debe emular esta capa. Esto es un
problema ya que la instancia de la red IP es solo una construcción virtual,
mientras que la realidad es una (potencialmente) gran cantidad de nodos
individuales, distantes entre sí tanto en una comunicación como en un sentido
físico.

Cada circuito virtual que atraviesa la red IP requiere control en dos nodos, que
se encuentran en las ubicaciones donde el circuito cruza desde la red ATM
hacia la red IP y viceversa. Como estos dos nodos están casi totalmente
alejados entre sí, desde la perspectiva de cada circuito virtual individual, estos
dos nodos deben tener una relación maestro / esclavo o cliente / servidor.

Ahora, para el control general de una instancia de red IP `switch ATM virtual
', hay dos arquitecturas posibles que se pueden considerar:

1. una arquitectura de control centralizada.

2. una arquitectura de control distribuido.

Veré las ventajas y desventajas de cada uno a su vez:

 Arquitectura de control centralizado

En esta arquitectura, un nodo actúa como la capa de red del conmutador

ATM, y todas las funciones de control ATM en toda la red IP se
manejan en este nodo. En algunos aspectos, esta es la solución más
fácil, aunque, al igual que con todas las arquitecturas cliente / servidor,
la escalabilidad puede ser un problema.

Hay cuatro problemas fundamentales con la arquitectura de control

centralizada:

1. Como la lógica de control está centralizada en un sitio, otros

sitios deben obtener permiso de este sitio cuando se deben tomar
decisiones. Esto puede conducir fácilmente a cuellos de botella
en este sitio central.
2. Si cada sitio remoto debe obtener permiso para sus acciones
desde un sitio central, esto necesariamente demora, ya que habrá
momentos en que el sitio remoto no podrá actuar, ya que está
esperando que se otorgue el permiso.
3. La posibilidad de falla en el sitio central siempre debe ser
considerada.
4. Existe un problema esotérico de compatibilidad con la filosofía
de Internet. Un principio básico de Internet es la falta de control
central, con autonomía en sitios individuales.

Se aprecia que cada uno de estos problemas puede mejorarse hasta

cierto punto mediante un diseño inteligente y la provisión de sistemas
redundantes, pero a menudo a costa de una mayor complejidad.

Arquitectura de control distribuido

En esta arquitectura, cada sitio tiene control autónomo sobre sus

funciones de control ATM, pero siempre debe comportarse de manera
que asegure que sus acciones no generen ambigüedad en otros sitios. La
arquitectura de control distribuido evita los posibles problemas del
control central, pero aumenta la complejidad de los protocolos
necesarios para que la arquitectura funcione correctamente.

En mi implementación, he utilizado una arquitectura de control distribuido

para la lógica de control ATM, con, para cada conexión de circuito virtual
individual, una relación maestro / esclavo entre los dos nodos en los bordes de
la red IP.

Extensiones de protocolo IP requeridas

Es evidente que el encabezado IP por sí solo no tiene suficiente información
para volver a crear la información del circuito virtual en el otro lado de la red
IP.

El requisito de que las celdas ATM lleguen en el mismo orden en el que

fueron transmitidas significa que se debe agregar alguna forma de secuencia.

La información en las células de señalización ATM y las células de gestión de

recursos ATM también debe transportarse de forma transparente a través de la
red IP.

UDP [ 6 ] es un protocolo de nivel de transporte simple y de mejor esfuerzo

que proporciona un puerto de origen de 2 bytes y campos de puertos de
destino. Estos, si se fusionan como un único campo de 4 bytes, podrían usarse
para transportar el encabezado de celda ATM (sin su campo HEC de 1 byte).

Sin embargo, esto no soluciona el requisito de incluir información de

secuencia.

TCP [ 7 ] es un protocolo capaz de transportar la información requerida. Sin

embargo, su inicio lento y complejos algoritmos de retransmisión lo hacen
demasiado engorroso para este propósito.

La alternativa es definir una nueva opción de IP y usar esto para mantener la

información de encabezado requerida. Decidí explorar esta opción aún más,
ya que además de proporcionar un mayor margen para diseñar un encabezado
con los campos exactos necesarios, evita la proliferación innecesaria de capas
de protocolo.

Las opciones de IP tienen un encabezado de 1 byte, que consiste en [ 2 ]:

 un campo Copia de 1 bit

 un campo de Clase de Opción de 2 bit
 un campo de número de opción de 5 bits

El campo Número de opción de 5 bits no se utiliza por completo, ya que solo

hay 8 opciones reconocidas en este momento, con espacio para otras 24
disponibles en un campo de 5 bits. Por lo tanto, es posible definir una nueva
opción de IP, y esta es la solución que decidí explorar.

Concatenación de células ATM en

paquetes IP
Para compensar el tamaño más grande del encabezado IP (20 bytes más la
opción IP) en comparación con el encabezado de la celda ATM (5 bytes), es
necesario agregar las cargas útiles de la celda en unidades más grandes. Hay
tres enfoques para esto:

1. Use una agregación que sea completamente independiente de la

agregación de capa AAL. Es decir, optimice la longitud de la carga útil
IP a la MTU de los enlaces dentro de la red IP, pero incluya la
consideración del tiempo de llegada entre paquetes y la posibilidad de
fluctuación de fase.
2. Utilice la agregación proporcionada por la capa AAL, de modo que
haya una correspondencia uno a uno entre la carga útil de una PDU
AAL y la carga útil de un datagrama IP.
3. Utilice la agregación proporcionada por la capa AAL como base, con
una mayor agregación en múltiples cargas útiles PDU AAL por
datagrama IP, si esto está garantizado.

Después de mucha consideración, decidí eliminar el primero de estos

enfoques por las siguientes razones:

La pérdida de paquetes y la corrupción de paquetes :

Si no existe una correlación entre el límite de los datagramas IP y las

PDU AAL, entonces es probable que la pérdida o corrupción de un
datagrama dé lugar a la falla en la recepción, no solo de esas PDU AAL
con cargas útiles dentro del datagrama IP, sino también esas PDU con
cargas útiles se dividen a través del límite entre el datagrama perdido o
dañado y el datagrama anterior o posterior. Por lo tanto, el daño
causado por la pérdida o corrupción de un datagrama se ve exacerbado.

Jitter :

En las aplicaciones en tiempo real, la trepidación ocurre cuando los

datos no llegan a la aplicación en el host de destino dentro de un
período de retardo establecido. La mayoría de las aplicaciones en
tiempo real empaquetan sus datos en el nivel PDU AAL en fragmentos
de tamaño "útil" , de manera que cada PDU contiene todos los datos
necesarios para continuar con la aplicación para el próximo período de
tiempo.

Si llega solo una parte de este fragmento de datos, la aplicación no

puede usarlo hasta que llegue el resto del fragmento , y debe almacenar
los datos entre tanto. Por lo tanto, para las aplicaciones en tiempo real,
la falta de correlación entre los límites del datagrama IP y los límites de
la PDU AAL puede ser un problema real.
 Retransmisión / recuperación de cargas útiles perdidas o dañadas :

El servicio de IP propuesto por este enlace ATM sobre IP es solo un

servicio de mejor esfuerzo. La recuperación de errores, si es necesario,
debe ser proporcionada por niveles más altos en los nodos finales del
cajero automático; no se proporciona en el límite ATM / IP. Los
datagramas IP dañados, como las células ATM dañadas, se descartan
discretamente sin generar mensajes de error. El nivel más bajo en el
cual la detección de datos perdidos puede comenzar a manejarse es el
nivel PDU AAL en los nodos finales ATM. Por lo tanto, si las cargas
útiles de PDU AAL se dividen en datagramas IP, la recuperación de
errores se retrasará en el mejor de los casos; en el peor, la corrección de
errores hacia adelante en aplicaciones en tiempo real puede ser
imposible.

El problema principal al generar una correspondencia entre el datagrama IP y

la PDU AAL es que un nodo en el límite ATM / IP debe saber qué capa de
adaptación se está utilizando. Esta información normalmente no está
disponible dentro de la capa ATM en el momento de la configuración de la
conexión. Puede inferirse de la negociación de Quality of Service, pero esto
sigue siendo un problema no resuelto.

Por supuesto, si AAL-5 se estandariza como la capa de adaptación utilizada

por todas las aplicaciones, como es muy posible, este problema desaparece
por completo. A los efectos de la modificación de la ATM _ TN simulador, he
asumido en efecto, que este es el caso.

Vinculación de nodos finales de IP a

nodos finales de ATM
El paso final en el diseño de un simulador totalmente multipropósito sería
habilitar los modelos de tráfico para vincular a un nodo final de IP en un
extremo, y a un nodo de extremo ATM en el otro.

La capacidad de hacer esta conexión aún no se ha agregado

al simulador ATM _ TN . Esto significa que los paquetes IP sin la opción ATM
sobre IP no deberían enviarse a los convertidores. Los convertidores, al no
encontrar la opción de IP que les indique cómo convertir el paquete en celdas
de ATM, simplemente descartarán el paquete de IP.

Hay problemas sustanciales involucrados en completar el modelo que aún no

he resuelto por completo.
  Para la red de cajeros automáticos, aparece toda una red IP como si
fuera un conmutador ATM. Por lo tanto, una conexión a un modelo de
tráfico desde la red IP se mostraría a la red ATM como si fuera una
conexión a un modelo de tráfico desde dentro de un conmutador. En la
actualidad, la ATM _ TN simulador trata conmutadores ATM y ATM
nodos finales de manera diferente, y no permite que los modelos de
tráfico a ser conectados a conmutadores ATM de esta manera.
 Los paquetes ATM sobre IP utilizan un protocolo IP que incluye una
opción IP, mientras que los paquetes IP generados en los nodos finales
IP no incluyen esta opción. Incluso si lo hicieran, no es fácil ver cómo
generar, en el nodo final de IP, la información que requieren los
campos de opción de IP.

Una posible solución a este impasse sería agregar funcionalidad adicional a un

convertidor para permitirle emular un nodo extremo ATM de la misma
manera que ahora emula un conmutador ATM. Esta modificación podría
lograrse con relativa facilidad.

Sin embargo, con el fin de engañar a la red ATM para que acepte esta
solución, la relación entre la topología ' REAL ' y la topología ' VIRTUAL '
de la red debería modificarse. En la topología ` VIRTUAL ', cada instancia de
red IP debería aparecer como un conmutador ATM conectado a` ` nodos
finales ATM, donde` ' es la cantidad de nodos finales IP dentro de la
instancia de red IP. Hacer esta modificación sería un desafío, aunque no
imposible.

La extensión propuesta del encabezado

IP
La opción de IP que propongo usar con ATM sobre IP es de 16 bytes (4
palabras) de longitud y tiene esta estructura:

Encabezado de opción de 1 byte [ 2 ].

Número de referencia de llamada de cajero automático de 3 bytes.

Esto es necesario para `demultiplexar 'los paquetes entrantes que

contienen información de señalización ATM en su carga útil.

Este número es único para una conexión dada donde el convertidor es

el maestro para esta conexión. Dado que un convertidor será, en
promedio, el maestro para la mitad de las conexiones, y el esclavopara
el resto, esto permitiría aprox. 32 millones de conexiones simultáneas a
través de cada convertidor, más que suficiente incluso para una red
Terabit. El caso `all bits set ' significa que este paquete no tiene
información de número de referencia de llamada y que los campos VP /
VC se usarán para la conmutación.

Número de secuencia de 4 bytes.

Esto es necesario porque, a diferencia de IP, ATM insiste en que las

células lleguen en el mismo orden de secuencia que se
transmitieron. Esta es la misma longitud que el número de secuencia
TCP.

Cabecera de celda ATM de 4 bytes (sin el cajero automático ATM de 1

byte).

Esto asegura que la información de VP / VC ATM requerida se

transmita a través de la red IP al otro lado.

Tenga en cuenta que si y luego la carga útil de este

paquete es información de señalización ATM y el campo de número de
referencia de llamada debe ser consultado.

Tipo de datos de 1 byte

Identifica el tipo de datos transportados en la carga útil. Solo se

consulta si el campo de número de referencia de llamada no tiene
`todos los bits establecidos ', este campo se usa cuando el datagrama
transporta información de control o señalización ATM. Un bit dentro
de este campo se usa para determinar si la información se transfiere
de Maestro a Esclavo o de Esclavo a Maestro .

CRC de 2 bytes

Esto se calcula tanto en la opción IP como en el encabezado IP. Se

prefiere un CRC de 16 bits a los habituales complemento de
encabezado IP porque es importante detectar todos los errores de
encabezado que ocurren dentro de la red IP, ya que las redes ATM
confían, para su correcto funcionamiento, en enlaces de tasa de error
muy bajos. Para que este CRC sea fácil de calcular, propongo que
dentro de estas redes ATM sobre IP, esta opción de IP siempre se
coloque por delante de otras opciones de IP.

Relleno de 1 byte.
 Esto consta de todos los ceros (la `` Lista de Fin de las Opciones '') si
no hay más opciones de IP en este paquete, o ( hex ) 10 si hay otras
opciones [ 2 ].

Consideraciones de topología de red

El ATM _ TN simulador genera la topología de la red simulada directamente
de los archivos de datos de entrada. Dado que, desde la perspectiva de ATM,
cada instancia de red IP debe aparecer como si fuera un "conmutador ATM",
se hace evidente que se requieren dos topologías.

Estas dos topologías son:

la topología `` REAL '' :

Esto consta de todos los nodos reales en el simulador, actualmente

nodos finales IP, nodos finales ATM, conmutadores ATM, enrutadores
IP y convertidores.

la topología `` VIRTUAL '' :

Esto consta de solo componentes ATM, más un tipo especial de

conmutador ATM "instancia de red IP". Por lo tanto, los nodos en
la topología `` VIRTUAL '' son nodos finales ATM y conmutadores
ATM, y las instancias de red IP aparecen como un tipo especial de
conmutador ATM.

Un convertidor tiene una única conexión ATM y una única conexión IP.

En el existente ATM _ TN simulador, nodos finales deben estar unidos a uno, y

sólo un conmutador ATM, y los modelos de tráfico (estos representan el
transporte y protocolos de capas superiores) se deben unir sólo a través de
nodos finales.

Para mantener esta coherencia, los conversores, que deben ocurrir en el límite
entre una red IP y una red ATM, deben estar conectados a uno, y solo a uno,
conmutador ATM y uno, y solo a uno, enrutador IP. Además de ser coherente
con la forma en que se construyen otras partes del simulador, esta es una
restricción completamente razonable.

En una implementación real, es probable que un convertidor sea una tarjeta

conectada a un enrutador de IP, y se requerirá una tarjeta para cada enlace de
ATM físico a ese enrutador de IP. Esto es topológicamente idéntico a la
situación simulada en ATM _ TN donde un convertidor tiene un solo enlace
ATM y un solo enlace IP, excepto que el enlace IP entre el convertidor y el
enrutador IP es arbitrariamente corto (es decir, tiene un retraso mínimo).

Emulando lógica de control de

conmutación en convertidores
Aquí hay tres fases distintas:

1. Antes de que comience la simulación, mientras se está construyendo la

topología de red, solo hay una instancia de la lógica de control del
conmutador para cada instancia de red IP.
2. Inmediatamente antes de que comience la simulación, a cada
convertidor se le entrega una copia de esta instancia de red IP. En esta
etapa, por lo tanto, la información almacenada en las tablas de capa de
red de conmutación de cada convertidor dentro de esta instancia de red
IP es idéntica.
3. A medida que avanza la simulación, cada convertidor es responsable de
mantener su propia capa de red de conmutadores, y solo tiene acceso a
la información que puede obtener localmente para hacerlo. Por lo tanto,
la información almacenada en cada convertidor será diferente.
Para cada conexión de circuito virtual individual, la capa de red en un
convertidor es el Maestro , el otro es el Esclavo . El maestro solo mantiene el
estado de señalización y control del cajero automático para esa
conexión. El Esclavo , en la medida de lo posible, permanece sin estado. Es
importante darse cuenta de que esta distinción se aplica solo al nivel de la
conexión individual, un convertidor que es un esclavopara una conexión
puede ser un maestro para otra conexión.

El convertidor que primero recibe la señal de solicitud de llamada

( NM _ SETUP ) para una nueva conexión de circuito virtual toma el rol
de maestro para esa conexión. Esta señal de solicitud de llamada llegará en el
enlace ATM al convertidor. Una señal de solicitud de llamada que llega a un
enlace IP ya debe haber pasado a través de la capa de conmutación de red de
otro convertidor, por lo tanto, un convertidor que recibe una señal de solicitud
de llamada en un enlace IP sabe que debe ser el esclavo para esta nueva
conexión de circuito virtual.

El convertidor maestro para cada conexión es el convertidor que toma las

decisiones de control para esa conexión, el convertidor esclavo simplemente
acepta esas decisiones, siempre que pueda hacerlo sin comprometer las
conexiones existentes.

Asignando un número de referencia de

llamada
Lo primero que hace un maestro cuando llega una nueva señal de solicitud de
llamada es asignarle un número de referencia de llamada único a esa
llamada. En un conmutador ATM este número de referencia de llamada es
único dentro de la lógica de control del conmutador, pero en el conmutador
distribuido que existe en la instancia de red IP no hay forma de saber que este
número de referencia de llamada asignado es único. Con la red IP, es
necesario utilizar el doble [ número de referencia de la llamada, ID
principal ] para tener un número de referencia de llamada único. El ID
maestro puede ser una forma única de identificar un convertidor dentro de una
red IP. En ATM _ TN , cada convertidor tiene una dirección IP única, por lo
que se usa.

Desafortunadamente, es probable que los conmutadores ATM ordinarios no

sepan, y no puedan, el doble [ número de referencia de llamada, ID
principal ] para la identificación de la llamada. Donde este es el caso, un
convertidor debe, si existe la posibilidad de conflicto, asignar un número de
referencia de pseudo llamada y mantener una tabla para mapear de números
de referencia de pseudo llamada a [ call number number, master ID ]
double. Esto solo será necesario para conexiones de circuitos virtuales donde
el convertidor es el esclavo , ya que el maestro siempre está en posición de
elegir un [ número de referencia de llamada, ID principal ] doble donde el
número de referencia de la llamada y el pseudo el número de referencia de
llamada es idéntico.

Este número de referencia de pseudo llamada es único solo con respecto a la

conexión entre el convertidor y el conmutador ATM ordinario
externo. Además, el mapeo del número de referencia [ número de referencia
de llamada, ID principal ] a pseudo llamada debe almacenarse solo en
el esclavo donde se utiliza. De hecho, es necesario que el Maestro no sepa
nada al respecto, ya que es completamente posible para otros convertidores,
actuando como Esclavos para otras conexiones con este mismo Maestro ,
elegir números de referencia de pseudo llamada idénticos . Si el maestro no
sabe nada de esto, la duplicación no importa.

Sin embargo, este requisito de que el Esclavo mantenga el [ número de

referencia de llamada, id. Maestro ] para pseudo llamar al mapeo del número
de referencia significa que ya no es totalmente apátrida con respecto a la
conexión.

Cuando un mensaje de control ATM (distinto de un mensaje de Solicitud de

llamada) llega a un convertidor en el enlace ATM, lo primero que debe hacer
la lógica de control es comprobar si se trata de un número de referencia
de pseudo llamada, y si es así, asignarlo al [ número de referencia de llamada,
ID principal ] doble. La lógica de control luego verifica este doble para
decidir si el convertidor está actuando como el Maestro o el Esclavo para esta
conexión. Si el convertidor es el esclavo para esta conexión, inmediatamente
pasa el mensaje de control al maestro . Si el convertidor es el maestro para
esta conexión, toma la acción apropiada como si fuera un interruptor ATM
común.

Con cada mensaje de control sobre la red IP de Maestro a Esclavo o

viceversa, debe haber suficiente información para identificar de manera única
la conexión antes de ejecutar el contenido del mensaje. Esto implica
identificar el [ número de referencia de llamada, ID principal ] doble del
mensaje de control entrante. El bit en el campo de tipo de las opciones de IP
se examina primero, para determinar si el convertidor es esclavo o maestro .

 Si el convertidor es un esclavo para esta conexión, se examinan

el campo de número de referencia de llamada en las opciones de IP y
el campo de dirección IP de origen en el encabezado de IP.
 Si el convertidor es un maestro para esta conexión, se examina
el campo de número de referencia de llamada en las opciones de IP y
la dirección IP propia del convertidor .
 Asignación y desasignación de índices
VP / VC
 La provisión de índices VP y VC únicos para cada conexión es una
función importante de la lógica de control del interruptor ATM. En un
conmutador ATM, la lógica de control sabe qué números VP y VC se
han asignado a las conexiones y qué números están disponibles para las
nuevas conexiones. Sin embargo, en la lógica distribuida
del conmutador ATM virtual de instancia de red IP , este conocimiento
ya no está disponible globalmente de forma instantánea dentro de la red
IP, y es posible concebir situaciones en las que a dos conexiones que
utilizan el mismo enlace físico se les asigna el mismo índice VP / VC
. Por lo tanto, los protocolos utilizados para asignar el índice VP / VC
deben diseñarse para evitar que se produzca este problema.
 Como los conversores maestro y esclavo están física y lógicamente
alejados el uno del otro, los protocolos de comunicación deben hacer
frente a la posibilidad de que un mensaje o su respuesta se pierda o se
corrompa en tránsito. Esto significa que cualquier comando
de Maestro a Esclavo debe ser reconocido, por lo que el Maestro sabe
que el Esclavo ha cumplido con el comando. Además, dado que el
mensaje de comando puede llegar, se puede llevar a cabo, pero el acuse
de recibo se pierde, las conexiones del esclavo deben ser capaces de
hacer frente a la situación en la que se envían el mismo mensaje más de
una vez.
 El maestro establece un temporizador con cada mensaje enviado. Si el
acuse de recibo no llega antes de que expire el temporizador, debe
asumir que el mensaje se perdió o se corrompió en tránsito.

El protocolo de asignación de índice VP /

VC Maestro / Esclavo
Para todas las conexiones en las que un convertidor es el maestro , el conflicto
del índice VP / VC no es un problema, ya que la lógica de control de la red del
convertidor sabe qué índices ya se ha asignado a sí mismo. Sin embargo, para
todas las conexiones en las que un convertidor es el Esclavo , el conflicto
ocurrirá si el Maestro le pide que asigne a una nueva conexión un índice que
sabe que ya ha sido asignado a otra conexión.

El Esclavo debe, en estas circunstancias, negarse a obedecer

las órdenes del Maestro . Puede hacerlo de forma pasiva o activa:

Rechazo activo :

El esclavo envía un mensaje NON _ COMPLY al maestro .

Rechazo pasivo :

El Esclavo simplemente ignora el comando.

En el caso de rechazo activo, el Maestro sabe si recibe

un NO _ CUMPLEN reconocimiento, la solicitud para asignar un índice de VP /
VC se negó, pero si no recibe ninguna respuesta reconocible hay tres
posibilidades:

1. La solicitud se perdió.
2. La solicitud llegó, fue aceptada y se perdió el reconocimiento
de CUMPLIR .
3. La solicitud llegó, se rechazó y se perdió el
reconocimiento NON _ COMPLY .

En el caso del rechazo pasivo, la ausencia de una respuesta todavía resuelve a

tres posibilidades:

1. La solicitud se perdió.
2. La solicitud llegó, fue aceptada y se perdió el reconocimiento
de CUMPLIR .
3. La solicitud llegó y fue rechazada.

He optado por el protocolo de rechazo pasivo en el código que he escrito para

el simulador ATM _ TN , ya que es un protocolo más simple y, con un diseño
cuidadoso, no menos eficiente que el protocolo de rechazo activo.

Tenga en cuenta que todos los mensajes de control incluyen un número de

referencia de llamada , y que esto se usa junto con la dirección de origen
IP (para un mensaje que llega al esclavo ) o la dirección
IPpropia del maestro (para un reconocimiento que llega al maestro ) para
identificar de forma única la conexión a la que se hace referencia.

El protocolo detallado es el siguiente:

El convertidor maestro envía al esclavo una lista de la longitud ' ' de los
índices potenciales de VP / VC, elegidos al azar, que, según el
mejor conocimiento del maestro , no están asignados actualmente ni se
ofrecen actualmente a otro esclavo. . (Tenga en cuenta que el maestro puede
estar involucrado en la configuración de más de una conexión en cualquier
momento dado). Al mismo tiempo, configura el temporizador.

Si puede hacerlo sin comprometer las asignaciones de índices existentes,

el Esclavo selecciona uno de los índices VP / VC y lo asigna a la
conexión. (Tenga en cuenta que debe verificar, no solo las conexiones
actualmente asignadas, sino también los índices VP / VC que,
como convertidor maestro para otras conexiones, tiene en oferta a
otros esclavos ). A continuación, registra la asignación de la [ referencia de
llamada número, ID principal ] al índice seleccionado en sus propias tablas, y
envía el índice seleccionado con el acuse de recibo COMPLETO .

De lo contrario, si ninguno de los índices de VP / VC en el mensaje

del Maestro se puede seleccionar con seguridad, el Esclavo no hace nada.

El maestro , al recibir el acuse de recibo COMPLETO , asigna el índice VP /

VC seleccionado a la conexión.

Como se estableció anteriormente, hay tres modos de falla. El protocolo no

debe colapsar si ocurre alguno de estos.

1. La solicitud se perdió.

El temporizador del Master expirará. El Maestro le enviará una nueva

lista aleatoria, recién elegido de los posibles índices de VP / VC.

2. La solicitud llegó, fue aceptada y se perdió el reconocimiento

de CUMPLIR .

El temporizador del Master expirará. El Maestro le enviará una nueva

lista aleatoria, recién elegido de los posibles índices de VP /
VC. El esclavo eliminará el índice VP / VC asignado y seleccionará
uno de la nueva lista para asignar a la conexión.

3. La solicitud llegó y fue rechazada.

El temporizador del Master expirará. El Maestro le enviará una nueva

lista aleatoria, recién elegido de los posibles índices de VP /
VC. El esclavo (si es posible) seleccionará uno de los índices VP / VC
de la nueva lista.

El protocolo es por lo tanto a prueba de fallas.

Lo que no se ha investigado es el mejor valor para ` ', el número de opciones
en la lista enviada de Maestro a Esclavo . Esto probablemente dependerá de

 la carga en la red.
 la cantidad de convertidores en la red.
 la frecuencia con la que se hacen y se derriban las conexiones.

El protocolo de desasignación del índice Maestro / Esclavo VP / VC

Esto es menos problemático para el diseño, aunque los modos de falla deben
volver a considerarse cuidadosamente. Mientras que en un mundo donde la
falla de comunicación no puede ocurrir, solo se requiere el [ número de
referencia de llamada, ID principal ] doble para identificar de forma única el
índice VP / VC para desasignar, la tolerancia a fallas requiere que el índice
VP / VC esté incluido en el mensaje.

Tenga en cuenta que siempre se devuelve un reconocimiento

de CUMPLIMIENTO al Maestro , incluso si no se produjo la desasignación. En
este sentido, el CUMPLIR reconocimiento sólo significa `` He recibido su
mensaje ''.

El protocolo detallado es el siguiente:

El Maestro envía al Esclavo un comando de desasignación, con el número de

referencia de la llamada y el índice VP / VC a eliminar (ambos son necesarios
para garantizar la posibilidad de que se produzcan errores en las condiciones
de falla). Al mismo tiempo, establece el temporizador.

El esclavo verifica el doble [ número de referencia de llamada, ID principal ]

y el índice VP / VC en el mensaje con la misma asignación en su propia tabla
de índices asignados y desasigna esto solo si las dos asignaciones
coinciden. Siempre envía un reconocimiento COMPLETO al maestro .

Nuevamente, hay tres modos de falla. El protocolo no debe colapsar si ocurre

alguno de estos.

1. La solicitud se perdió.

El temporizador del Master expira. El Maestro repite el mensaje.

2. Llegó la solicitud, se desasignó el índice VP / VC y se perdió el

reconocimiento.
 El temporizador del Master expira. El Maestro repite el
mensaje. El esclavo no puede desasignar el índice ya que esto ya se ha
hecho. Sin embargo, todavía envía un reconocimiento COMPLETO .

3. Llegó la solicitud, se desasignó el índice VP / VC, se perdió el acuse de

recibo y, mientras tanto, el índice VP / VC se reasignó a otra conexión.

El temporizador del Master expira. El Maestro repite el

mensaje. El esclavo verifica el mensaje con la asignación en su propia
tabla y se da cuenta de que no coinciden. No desasignar la asignación
índice de VP / VC, pero todavía envía una CUMPLIR acuse de recibo.

El protocolo es por lo tanto a prueba de fallas.

Capas de adaptación ATM, AAL-5 y

SAAL
Una vez tomada la decisión de usar paquetes de capas de adaptación para
guiar los parámetros utilizados al ensamblar cargas útiles de células en
datagramas de IP, ahora debemos considerar la implementación de esta
decisión en el diseño de los convertidores. He utilizado AAL-5 como la capa
de adaptación, ya que se utiliza en el modelo de tráfico TCP que se está
simulando.

Aunque, desde una perspectiva SAR, SAAL y AAL-5 son casi idénticos, se
usan LP separados dentro de los convertidores para las capas de adaptación de
datos y adaptación de datos.

Hay dos razones para esto:

1. Cualquiera de la capa de adaptación de datos y los LP de la capa de

adaptación de señalización pueden ser reemplazados
independientemente sin que el otro se vea afectado.
2. Desde una perspectiva pragmática, la forma en que
el simulador ATM _ TN ha sido diseñado, las capas de adaptación de
señalización (SAAL) y datos (AAL-5) han sido implementadas con
codificación completamente diferente y es imposible reconciliarlas en
un solo LP sin reescribir completamente uno o el otro (o ambos).
Modo de transferencia asincrónica
(ATM)
ATM [ 5 ] es una tecnología de conmutación y multiplexación de capa de
enlace, basada en células, diseñada para ser utilizada como un modo de
transferencia orientado a la conexión y de propósito general para una amplia
gama de servicios. Las celdas en ATM son de tamaño fijo con una longitud de
encabezado de 5 bytes y una carga útil de 48 bytes. Las celdas se mapean en
una ruta de transmisión física, generalmente dentro de tramas SONET que
normalmente se transmiten a través de conexiones de fibra óptica.

Las conexiones virtuales ATM pueden operar a una tasa de bit constante o
variable, y cada celda en la red contiene información de direccionamiento que
establece una conexión virtual desde el origen hasta el destino. Todas las
celdas se transfieren, en secuencia, a través de esta conexión virtual. ATM
proporciona conexiones virtuales permanentes y conmutadas.

El cajero automático maneja el tráfico orientado a conexión y sin conexión a

través de capas de adaptación (AAL), de las cuales cuatro se han especificado:

AAL-1 para tráfico constante de velocidad de bits (CBR).

AAL-2 para tráfico de audio y video paquetizado variable a velocidad de bits (VBR).

AAL-3/4 para tráfico VBR en modo orientado a la conexión y sin conexión.

AAL-5 una capa ligera de AAL para el tráfico de VBR.

Protocolo de Internet (IP)

La comunicación de datos eficiente requiere la capacidad de que las
computadoras con hardware diferente y el uso de diferentes sistemas
operativos se comuniquen directamente entre sí, independientemente de sus
conexiones físicas de red. Esto ha llevado al desarrollo de varias tecnologías
de red para vincular los sistemas informáticos.

La integración de estas redes dispares requiere una capa adicional de

tecnología conocida como internetworking y el desarrollo de protocolos para
permitir que se lleve a cabo esta interconexión.

Internet es un sistema global de redes interconectadas que utilizan un

protocolo común de internetworking conocido como el Protocolo de
Internet. IP ha sido diseñado para funcionar sobre casi cualquier protocolo de
capa de enlace, y esta es una de las razones de la rápida aceptación y difusión
mundial de Internet.

IP proporciona un mejor servicio de entrega de datagramas sin conexión en la

capa de red, utilizando datagramas de longitud variable con encabezados de
20 bytes. Por lo general, IP requiere una capa de enlace para manejar las
conexiones salto por salto, aunque es posible usar IP sin esta capa.

Dos protocolos principales de capa de transporte usan IP. UDP [ 6 ], al igual

que su capa de red subyacente, es el mejor servicio de entrega de datagramas
sin conexión, mientras que TCP [ 7 ] desarrolla un protocolo de transmisión
de datos confiable, orientado a la conexión que usa datagramas IP.