Tabla de contenidos API de TCP

2.13 ATM("Asynchronous Transfer Mode")

Las redes basadas en ATM están teniendo un creciente interés para las aplicaciones, tanto LAN como WAN. Ya hay algunos productos disponibles para construir una red física ATM propia. La arquitectura ATM es nueva y distinta de las arquitecturas LAN estándar. Por este motivo, son necesarios cambios para que los productos LAN tradicionales funcionen en entornos ATM. En el caso de TCP/IP, el principal cambio está en la interfaz de red para que soporte ATM.

Existen ya varios enfoques del problema, dos de los cuales son importantes para el transporte del tráfico TCP/IP. Se describen en IP clásico sobre ATM y Emulación LAN con ATM. También se comparan en IP clásico sobre ATM versus emulación LAN.

2.13.1 Resolución de direcciones(ATMARP y InATMARP)

La resolución de direcciones en una subred lógica IP de ATM la hace el ATMARP ("ATM Address Resolution Protocol") basado en el RFC 826 y en el InATMARP("Inverse ATM Address Resolution Protocol") basado en el RFC 1293. ATMARP es el mismo protocolo que ARP pero con las extensiones necesarias para que ARP funcione en el entorno de servidor unicast de ATM. InATMARP es el mismo protocolo que el InARP original, pero aplicado a redes ATM. El uso de estos protocolos difiere en si se utilizan o no PVCs o SVCs.

Tanto ATMARP como InATMARP están definidos en el RFC 1577, que es una propuesta de estándar con estado electivo.

La encapsulación de las peticiones/respuestas de InATMARP y ATMARP se describe en IP clásico sobre ATM.

2.13.1.1 InATMARP

El protocolo ARP se usa para calcular la dirección hardware de un host a partir de su dirección IP. El protocolo InATMARP se usa para calcular la dirección IP de un host a partir de su dirección hardware. En un entorno conmutado, primero se establece una VC("Virtual Connection") o una PVC("Permanent Virtual Connection") o una SVC("Switched Virtual Connection") para comunicar con otra estación. Por lo tanto, se sabe la dirección hardware del otro host, pero no la dirección IP. InATMARP proporciona resolución dinámica de direcciones. Utiliza el mismo formato de trama que el ARP estándar , pero define dos nuevos códigos de operación:

Ver Generación del paquete ARP para más detalles.

El InATMARP básico opera esencialmente del mismo modo que ARP, con la excepción de que no hace las peticiones con broadcasts. Esto se debe a que la dirección hardware ya se conoce. Una estación solicitante simplemente formatea una petición insertando sus direcciones hardware de IP(fuente) y la dirección hardware del destino. Luego rellena con ceros el campo de dirección IP del destino y envía el mensaje a la estación de destino. Para cada petición InATMARP, la estación receptora formatea una respuesta utilizando la dirección fuente de la petición como dirección de destino para la respuesta. Ambos extremos actualizan sus tablas ARP. El valor tipo de hardware para ATM es el 19 decimal y el campo EtherType se pone a 0x806, que indica ARP según el RFC 1700.

2.13.1.2 Resolución de dirección en el entorno PVC

En un entorno PVC cada estación utiliza el protocolo InATMARP para determinar las direcciones IP de todas las demás estaciones conectadas. La resolución se hace para aquellos PVCs configurados para la encapsulación LLC/SNAP. Es responsabilidad de cada estación IP que soporte PVCs la revalidación de las entradas de la tabla ARP a medida que pasa el tiempo.

2.13.1.3 Resolución de direcciones en el entorno SVC

SVCs requiere soporte para ATMARP en el entorno no-broadcast de ATM. Para hacer frente a esta necesidad, se debe localizar un único servidor ATMARP dentro de la LIS("Logical IP Subnetwork"; ver LIS("Logical IP Subnetwork")). Este servidor tiene la responsabilidad de resolver las peticiones ATMARP de todos los miembros IP del LIS. Para una explicación de los términos ATM, remitirse a IP clásico sobre ATM.

El servidor en sí mismo no establece conexiones de modo activo. El inicio del proceso de registro ATMARP depende el cliente del LIS. Un cliente individual se conecta al servidor ATMARP con una conexión punto a punto VC. El servidor, al completarse la conexión ATM de un nuevo VC con encapsulación LLC/SNAP, transmitirá un petición InATMARP para determinar la dirección IP del cliente. La respuesta InATMARP del cliente contiene la información necesaria para que el servidor construya su caché ATMARP. Esta tabla consiste en:

Esta información se usa para generar respuestas a las peticiones ATMARP recibidas.

Nota: El servidor ATMARP requiere que cada cliente sea configurado administrativamente con la dirección ATM del servidor ATMARP.

Algoritmo de inserción/actualización de la tabla ARP:
Degeneración de la tabla ATMARP

Las entradas de la tabla ATMARP son válidas:

Antes de invalidar una entrada de su tabla, el servidor ATPARP genera un InARP_REQUEST para cualquier VC abierto asociado con esa entrada y decide lo que ha de hacer de acuerdo con las siguientes reglas:

Por tanto, si el cliente no mantiene un VC abierto al servidor, debe refrescar su información ATMARP en el servidor al menos cada 20 minutos. Esto se hace abriendo un VC al servidor de intercambiando los paquetes InATMARP iniciales.

El cliente maneja las actualizaciones de la tabla con el siguiente criterio:

Como se menciona arriba, cualquier cliente IP de ATM que use SVCs debe conocer la dirección de su servidor ATM para el LIS concreto. Esta dirección se le debe indicar a cada cliente durante la configuración. Por el momento no hay ninguna dirección ATMARP bien conocida.

2.13.2 IP clásico sobre ATM

Las definiciones de implementaciones de IP clásico sobre ATM se describen en el RFC 1577, que es una propuesta de estándar con status electivo según el RFC 1720(STD 1). Este RFC considera sólo la aplicación de ATM como una sustitución directa de los "cables"("wires"), segmentos LAN locales que conectan estaciones IP como extremos de la conexión("members") y "routers" que operan sobre el paradigma LAN clásico. Las consecuencias derivadas de los puentes a nivel MAC y de la emulación LAN no se tienen en cuenta.

Una distribución inicial de ATM proporciona una sustitución de los segmentos LAN por:

Este RFC describe también extensiones al ARP(RFC 826). Este tema se discute aparte en Resolución de direcciones(InATMARP y ATMARP).

Algunos fundamentos de ATM:

Celdas
Todo tipo de información(voz, imágenes, vídeo, datos, etc.) se transporta a través de la red en bloques muy pequeños(48 bytes de datos más una cabecera de 5 bytes) llamados celdas.
Encaminamiento
El flujo de información se produce a lo largo de rutas(llamadas "canales virtuales") establecidas como una serie de punteros por la red. La cabecera de una celda contiene un identificador que vincula la celda al camino correcto que debe tomar para llegar a su destino.
Las celdas de un canal virtual particular siempre siguen el mismo camino y se entregan en el destino en el mismo orden en el que llegaron al canal.
Conmutación por hardware
ATM está diseñado de tal forma que se emplean simples elementos de lógica hardware en cada nodo para realizar la conmutación. En un enlace de 1 Gbps llega una nueva celda, y se transmite una celda cada 0.43 microsegundos. El tiempo de conmutación es mínimo.
Conexión virtual VC
ATM proporciona un entorno conmutado VC("Virtual Connection"). El VC se puede establecer bien a partir de un PVC("Permanent Virtual Connection") o de un SVC("Switched Virtual Connection") dinámico. La gestión de SVC hace con implementaciones del protocolo Q.93B.
Interfaz de usuario final
La única forma para que un protocolo de nivel superior se comunique sobre una red ATM es por medio de la capa ATM AAL("ATM Adaptation Layer"). La función de esta capa es realizar el mapeado entre las PDUs y las celdas. Hay cuatro tipos diferentes de AAL, AAL1, AAL2, AAL3/4 Y AAL5. Estos AALs ofrecen distintos servicios a los protocolos de nivel superior. Aquí se muestran las características de AAL5, usado para TCP/IP:
AAl5 proporciona las mismas funciones que una LAN en el nivel MAC("Medium Access Control"). Los extremos del VC saben el tipo de AAL por medio del mecanismo de configuración de la celda, por lo que la cabecera de la celda no ha de llevarlo. Para los PVCs el tipo AAL se configura administrativamente en los extremos cuando se establece la conexión. ara los SVCs, el tipo de AAL se comunica por el canal vía 0.93B como parte de la solicitud de establecimiento y definición de la conexión y los extremos usan las señales de control para configurarse. Los conmutadores ATM no suelen preocuparse del tipo de AAL de los VCs. El formato AAL5 especifica un formato de paquete con un tamaño máximo de 64KB - 1 byte de usuario. Las "primitivas" que ha de usar el protocolo de nivel superior como interfaz con la capa AAL(en el SAP de AAL("Service Access Point") están definidas rigurosamente. Cuando un protocolo de nivel superior envía datos, estos son procesados primero por la capa de adaptación, luego por ATM y por último la capa física se encarga de enviar los datos por la red ATM. Las celdas se transportan y las recibe el otro extremo de la conexión en su capa física, que las pasa a ATM, que tras procesarlas las pasa al AAL receptor, que a su vez devuelve los datos al nivel superior. La función total que ha realizado la red ATM ha sido un transporte no garantizado de información(se podría haber perdido una parte). Desde un punto de vista más conservador del proceso de datos, todo lo que ha hecho la red ATM ha sido sustituir un enlace físico por otro tipo de conexión física - todos los protocolos de alto nivel siguen teniendo que efectuarse(por ejemplo IEEE 802.2).
Direccionamiento
Una dirección ATM de un extremo de la conexión se codifica bien como una dirección de 20 bytes basada en OSI NSAP(utilizada para direccionamiento en redes privadas, con tres formatos posibles) o como una dirección E.164 Public UNI(del estilo de los números telefónicos, usados para redes TM públicas).(5)
Broadcast, Multicast
En la actualidad no hay funciones de broadcast similares a las de las LANs. Pero sí existe una función de multicast. El término ATM para multicast es "conexión punto - multipunto".

2.13.2.1 LIS("Logical IP Subnetwork")

El término LIS se introdujo para mapear la estructura lógica de IP a la red ATM. En el contexto LIS, cada entidad administrativa independiente configura sus hosts y "router" dentro de una red IP. Cada LIS opera y se comunica con independencia de otros LIS de la misma red ATM. Los host conectados a una red ATM se comunican directamente con otros hosts dentro del mismo LIS. Esto implica que todos los miembros de un LIS sean capaces de comunicarse con otros hosts del mismo LIS por medio de ATM. La comunicación con hosts externos al propio LIS requiere un "router". El "router" es un extremo ATM conectado a la red ATM que se configura como un miembro de uno o más LISs. Esta configuración puede dar lugar a un número de LISs distintos operando sobre la misma red ATM. Los hosts de diferentes subredes deben usar un "router" aunque se pueda abrir un VC entre ellos a través de ATM.

2.13.2.2 Encapsulación multiprotocolo

Si se desea usar más de un tipo de protocolo de red(IP, IPX, etc.) concurrentemente en una red física, se necesita una forma de multiplexar los distintos protocolos. Esto se puede hacer en el caso de ATM con una multiplexación basada en VC o en LLC. Si se elige multiplexación por VC, hay que tener un VC para cada protocolo entre los dos hosts. La encapsulación LLC proporciona la función de multiplexación en la capa LLC y por tanto sólo requiere un VC. TCP/IP usa, según los RFCs 1577 y 1483, el segundo método debido a que esta forma de multiplexado ya estaba definida en el RFC 1042 para otros tipos de LAN como Ethernet, FDDI y redes en anillo. Con esta definición, IP simplemente usa ATM en vez de una LAN. Todos los demás beneficios que ofrece ATM, como el transporte de tráfico isócrono, etc., no se utilizan. Hay un grupo IETF trabajando en la mejora de la implementación de IP y su interfaz con ATM.

Para ser precisos, la PDU de TCP/IP se encapsula en una cabecera IEEE 802.2 LLC seguida de una cabecera IEEE 802.1a SNAP("SubNetwork Attachment Point") transportada dentro del campo de carga útil("payload field") de una PDU AAL5 CPCS("Common Part Convergence Sublayer"). El formato de la PDU AAL5 CPCS se muestra en Figure - Formato de la PDU AAL5 CPCS.


Figure: Formato de la PDU AAL5 CPCS

CPCS-PDU Payload
Mostrado en Figura - Formato del Payload de CPCS para PDUs de IP.
Pad
Se utiliza como relleno para que el tamaño de CDCS se ajuste a las cedas ATM.
CPCS-UU
El campo CPCS-UU ("User-to-User identification") se usa para transmitir de forma transparente información de usuario a usuario. Este campo no tiene utilidad en la encapsulación y se le puede dar cualquier valor.
CPI
El campo CPI ("Common Part Indicator") alinea la cola del CPCS a 64 bits.
Length
El campo Length indica la longitud, en bytes, del campo Payload. El valor máximo es 65535(64KB - 1)
CRC
El campo CRC protege todo el CPCS exceptuándose a sí mismo.

El formato del campo Payload para las PDUs enrutadas se muestra en Figura - Formato del Payload de CPCS para PDUs de IP.


Figura: Formato del Payload de CPCS para PDUs de IP

IP PDU
Dat IP normal comenzando con la cabecera IP.
LLC
Cabecera LLC de 3 bytes con el formato DSAP-SSAP-Ctrl. Para datos IP se pone a 0xAA-AA-03 para indicar la presencia de una cabecera SNAP. El campo Ctrl tiene siempre el valor 0x03 especificando una PDU de tipo "Unnumbered Information Command".
OUI
El campo de 3 bytes OUI ("Organizationally Unique Identifier") identifica una organización que administra el significado del PID(explicado a continuación). Para especificar el tipo EtherType en el PID el OUI tiene que ponerse a 0x00-00-00.
PID
El PID("Protocol Identifier") de 2 bytes el tipo de protocolo de la PDU que le sucede. Para datagramas IP, el PID es 0x08-00.

El tamaño por defecto de la MTU para miembros IP de la red ATM se discute en el RFC 1626 y se fija a 9180 bytes. La cabecera LLC/SNAP es de 8 bytes; por consiguiente, el tamaño por defecto de la PDU ATM AAL5 es de 9188 bytes. Se puede cambiar el tamaño de la MTU, pero debe hacerse por igual para todos los miembros del LIS. El RFC 1755 recomienda que todas las implementaciones soporten tamaños de MTU de hasta 64KB, inclusive.

No hay forma de mapear direcciones IP de broadcast o de multicast a ATM. Sin embargo, no hay restricciones para transmitir o recibir datagramas especificando cualquiera de las cuatro dirección de broadcast estándar de IP descritas en el RFC 1122. Los miembros, al recibir un broadcast IP para su LIS, deben procesar el paquete como si fuera para ellos.

2.13.3 Emulación LAN con ATM

Otra forma de proporcionar un medio de migrar a una red ATM nativa es la emulación LAN por ATM. Aún está en fase de diseño, de manos de los grupo de trabajo del Forum de ATM. Remitirse a IP clásico sobre ATM para conocer el punto de vista del IETF. No existe consenso en lo que respecta a la implementación de una LAN virtual sobre ATM, aunque si hay algunos puntos de común acuerdo acerca de las distintas propuestas hechas al Forum de ATM.

Tabla de contenidos TCP/IP y OSI