Tabla de contenidos 
API de TCP Tabla de contenidos API de TCP
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.
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.
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.
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.
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.
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.
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:
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.
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
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
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.
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.
TCP/IP y OSI