Las redes basadas en ATM están tomando interés en las aplicaciones de área local y ancha. Hay disponibles ya algunos productos para implementar redes físicas ATM. La arquitectura ATM es nueva, por lo tanto, diferente de las LAN estándar. Por esta razón, se requieren cambios así que los productos de LAN tradicionales trabajarán en el entorno ATM. En el caso de TCP/IP, el cambio principal a realizar es en la interfaz de red para proporcionar soporte a ATM.
Hay muchos enfoques disponibles en estos momentos, dos de los cuales son importantes para el transporte del tráfico de TCP/IP. Estos se describen en IP clásico sobre ATM y emulación de LAN ATM. También se comparan IP clásico sobre ATM contra la emulación de LAN.
Resolución de Direcciones
(ATMARP e InATMARP)
La resolución de direcciones en una subred IP lógica ATM se lleva a cabo mediante el Protocolo de Resolución de Direcciones de ATM (ATMARP) basada en RFC 826 y el Protocolo de Resolución de Direcciones ATM Inverso. ATMARP es el mismo protocolo que el ARP con extensiones necesarias para soportar ARP en un entorno servidor unicast ATM. InATMARP es el mismo protocolo que el protocolo original InARP pero aplicado a redes ATM. El uso de estos protocolos depende de si utilizamos PVCs o SVCs.
ATMARP y InATMARP se definen en el RFC 1577, que es un estándar propuesto pero próximamente aceptado.
La encapsulación de peticiones ATMARP y InATMARP se describe en IP clásico sobre ATM.
InATMARP
El protocolo ARP se usa para resolver una dirección hardware de un host una dirección IP conocida. El protocolo InATMARP se usa para resolver una dirección IP de host por una dirección conocida de hardware. En un entorno conmutado primero se establece una CV (Conexión Virtual) de cada CVP (Conexión Virtual Permanente) o CVC (Conexión Virtual Conmutada) para comunicar con otra estación. Por tanto, se conoce la dirección exacta de hardware del partner by administration pero la dirección IP se desconoce. InATMARP proporciona resolución de direcciones dinámica.
InARP usa el mismo formato de trama que el estándar ARP pero define dos nuevos códigos de operación:
- petición InARP=8
- respuesta InARP=9
Véase Generación de Paquetes ARP para más detalles.
El InATMARP básico opera esencialmente igual que ARP exceptuando que InATMARP no hace peticiones broadcast. Esto es porque la dirección hardware de la estación de destino ya se sabe. Una estación de peticiones simplemente formatea una petición insertando su hardware origen y dirección IP y la dirección hardware de destino conocida. Luego rellena con ceros el campo de dirección de protocolo de destino y lo envía directamente a la estación de destino. Para cada petición InATMARP, la estación receptora formatea una respuesta usando la dirección de origen de la petición como la dirección origen de la respuesta. Ambos lados actualizan sus tablas ARP. El valor del tipo de hardware para ATM es 19 en decimal y el campo EtherType se pone a 0x806, lo que indica ARP según el RFC 1700.
Resolución de direcciones en un entorno CVP
En un entorno PVC cada estación usa el protocolo InATMARP para determinar las direcciones IP de las otras estaciones conectadas. La resolución se hace para estos PVCs lo cuales se configuran para encapsulación LLC/SNAP. Esta es la responsabilidad de cada estación IP soportando PVCs para volver a validar las entradas de la tabla ARP como parte del proceso de envejecimiento.
Resolución de direcciones en un entorno CVC
Las CVCs requieren soporte para ATMARP en el entorno no-broadcast de ATM. Para encontrar esta necesidad, un sólo servidor ATMARP debe localizarse en la Subred IP Lógica (LIS) (ver La Subred IP Lógica (LIS)). Este servidor tiene responsabilidad autoritaria para resolver las peticiones ATMARP de todos los miembros IP con la LIS. Para explicaciones en términos de ATM ir a IP clásico IP sobre ATM.
El propio servidor no establece activamente conexiones. Ello depende de los clientes en el LIS para iniciar el procedimiento de registro ATMARP. Un cliente individual se conecta al servidor ATMARP usando un CV punto-a-punto. El servidor, en la terminación de una llamada/conexión ATM de un nuevo CV especificando encapsulación LLC/SNAP, transmitirá una petición InATMARP para determinar la dirección IP del cliente. La respuesta InATMARP del cliente contiene la información necesaria para el servidor ATMARP para construir su tabla ATMARP.
Esta tabla consiste en:
- La dirección IP
- La dirección ATM
- Timestamp
- CV asociado
Esta información se utiliza para generar respuestas a las peticiones que ATMARP recibe.
Nota: El mecanismo del servidor ATMARP requiere que cada cliente sea configurado administrativamente con la dirección ATM del servidor ATMARP.
Algoritmo añade/actualiza tabla ARP:
- Si el servidor ATMARP recibe una nueva dirección IP en una respuesta InATMARP se añade a la tabla ATMARP esa dirección IP.
- Si la dirección IP InATMARP duplica una drección IP de entrada en la tabla y la dirección InATMARP ATM no coincide con la dirección ATM de la entrada de la tabla y existe un CV asociado abierto con esa entrada de la tabla, la información InATMARP se descarta y no se realiza modificación alguna a la tabla.
- Cuando el servidor recibe una petición ATMARP sobre un CV, donde el IP de origen y la dirección ATM coinciden the association already in the ATMARP table y the ATM address matches that associated with the VC, the server updates the timeout on the source ATMARP table entry. For example, if the client is sending ATMARP requests to the server over the same VC that it used to register its ATMARP entry, the server notes that the client is still "alive" y updates the timeout on the client's ATMARP table entry.
- When the server receives an ARP_REQUEST over a VC, it examines the souinformation. If there is no IP address associated with the VC over which the ATMARP request was received y if the source IP address is not associated with any other connection, then the server adds this station to its ATMARP table. This is not the normal way because, as mentioned above, it is the responsibility of the client to register at the ATMARP server.
Envejecimiento de la tabla ATMARP
Las entradas de la tabla ATMARP son válidas:
- En clientes para un tiempo máximo de 15 minutos.
- En servidores para un tiempo mínimo de 20 minutos.
Antes de que envejezca una entrada en la tabla ATMARP, el servidor ATMARP genera una petición InARP en un CV asociado que esté abierto con esa entrada y decide qué hacer según las siguientes reglas:
- Si se recibe una respuesta InARP esa entrada se actualiza y no se borra.
- Si no existe CV asociado abierto con esa entrada se elimina.
Por tanto, si el cliente no mantiene un CV abierto al servidor, el cliente debe refrescar su información ATMARP con el servidor al menos una vez cada 20 minutos. Esto se hace abriendo un CV al servidor y cambiando los paquetes iniciales InATMARP.
El cliente hyles las actualizaciones de la tabla según lo siguiente:
- Cuando una entrada de la tabla ATMARP envejece, el cliente ATMARP invalida esta entrada.
- Si no hay un CV asociado con la entrada invalidada, esa entrada se borra.
- En el caso de una entrada invalidada y un CV abierto, el cliente ATMARP revalida la entrada prior to transmitir alguna non-address resolution traffic en ese CV. Hay dos posibilidades:
- En el caso de un CVP, el cliente valida la entrada transmitiendo una petición InARP y actualizando la entrada on receipt de una repuesta InARP.
- En el caso de un CVS, el clente valida la entrada transmitiendo una repuesta ARP al servidor ATMARP y actualizando la entrada on receipt de una respuesta ARP.
- Si un CV con una entrada de la tabla ATMARP invalidada asociada se cierra, esa entrada se elimina.
Como se mencionó anteriormente, cada cliente IP ATM que usa CVSs debe saber la dirección de su dirección ATM del servidor ATMARP para el LIS particular. Esta dirección se debe referenciar en cada cliente durante la configuración. Actualmente no hay direcciones de servidores ATMARP "conocidas".
IP Clásico sobre ATM
Las definiciones para realizaciones de IP clásico sobre ATM (Modo de Transferencia Asíncrona) se describen en el RFC 1577 which is a proposed estándar con un estado de elective según el RFC 1720 (STD 1). Este RFC considera sólo la aplicación de ATM como un reemplazo directo del "cableado", segmentos locales LAN conectando estaciones-terminales IP ("miembros") y routers operando en el paradigma basado en LAN "clásico". Issues raised by MAC level bridging y LAN emulation are not covered.
Despliegue iniciales de ATM proporcionan un reemplazo de segmentos LAN para:
- Redes Ethernets, token-rings o FDDI.
- Local-area backbones entre LANs (no-ATM) existentes.
- Circuitos dedicados de Frame Relay CVPs entre routers IP.
Este RFC también describe extensiones para el protocolo ARP (RFC 826) in order to trabajar sobre ATM. Esto se discute separadamente en: Resolución de Direcciones (ATMARP y InATMARP).
Primero algo básico de ATM:
- Celdas
- Toda la información (voz, imágenes, vídeo, datos, etc.) se transporta a través de la red en unos bloques muy pequeños llamados celdas (48 bytes de datos más una cabecera de 5 bytes).
Encaminamiento- El flujo de información se realiza a lo largo de trayectorias (llamadas "canales virtuales") configuradas como una serie de punteros a través de la red. La cabecera de la celda contiene un identificador que enlaza la celda a la trayectoria correcta que tomará hacia su destino.
Las celdas de un canal virtual particular siempre siguen la misma trayectoria a través de la red y son transportadas al destino en el mismo orden en que fueron recibidas.
- Conmutación basada en Hardware
- ATM está diseñada para que elementos lógicos basados en hardware simple se deban emplear en cada nodo para mejorar la conmutación. En un enlace de 1 Gbps llega una nueva celda y una celda se transmite cada 0.43 microsegundos. No hay mucho tiempo para decidir que hacer con un paquete que llega.
Conexión Virtual CV- ATM proporciona un entorno conmutado de Conexión Virtual. La configuración de la CV debe hacerse tanto en una Conexión Virtual Permanente (CVP) o una Connexión Virtual Conmutada (CVC) dinámica básica. El manejo de la llamada CVC se lleva a cabo vía implementaciones del protocol Q.93B.
Fin-Interfaz-Usuario- La única manera que tiene un protocolo for a higher layer protocol to communicate across an ATM network is over the ATM AAL (ATM Adaptation Layer). The function of this layer is to perform the mapping of PDUs (Protocol Data Units) into the information field of the ATM cell y vice versa. There are four different AAL types defined, AAL1, AAL2, AAL3/4 y AAL5. These AALs offer different services for higher layer protocols. Here are the characteristics of AAL5 which is used por TCP/IP:
- Modo Mensaje y modo flujo.
- Transporte Assured.
- Transporte Non-assured (usado por TCP/IP).
- Segmentación de datos.
- Operación Multipunto.
AAL5 provides the same functions as a LAN at the MAC (Medium Access Control) layer. The AAL type is known by the VC endpoints via the cell setup mechanism y is not carried in the ATM cell header. For PVCs the AAL type is administratively configured at the endpoints when the Connection (circuit) is set up. For SVCs, the AAL type is communicated along the VC path via Q.93B as part of call setup establishment y the endpoints use the signaled information for configuration. ATM switches generally do not care about the AAL type of VCs. The AAL5 format specifies a packet format with a maximum size of 64KB - 1 byte of user data. The "primitives" which the higher layer protocol has to use in order to interface with the AAL layer (at the AAL service access point - SAP) are rigorously defined. When a high-layer protocol sends data, that data is processed first by the adaptation layer, then by the ATM layer y then the physical layer takes over to send the data to the ATM network. The cells are transported by the network y then received on the other side first by the physical layer, then processed by the ATM layer y then by the receiving AAL. When all this is complete, the information (data) is passed to the receiving higher layer protocol. The total function performed by the ATM network has been the non-assured transport (it might have lost some) of information from one side to the other. Looked at from a traditional data processing viewpoint all the ATM network has done is to replace a physical link connection with another kind of physical connection - all the "higher layer" network functions must still be performed (for example IEEE 802.2).
Direccionamiento- An ATM Forum endpoint address is either encoded as a 20-byte OSI NSAP-based address (used for private network addressing, three formats possible) or is an E.164 Public UNI address (telephone number style address used for public ATM networks). (5)
Broadcast, Multicast- No existe actualmente funciones broadcast similares a las que proporciona una LAN. Pero hay una función multicast disponible. El término ATM para multicast es "conexión punto-a-multipunto".
Subred Lógica IP (LIS)
El término LIS se introdujo para hacer corresponder la estructura lógica IP a la red ATM. En un escenario LIS, cada entidad administrativa configura por separado sus hosts y routers con una subred lógica cerrada (de la misma forma que un número de red/subred IP y máscara de dirección). Cada LIS opera y se comunica independientemente de otros LISs de la misma red ATM. Los hosts que se conectan a un red ATM se comunican directamente a otros hosts con el mismo the same LIS. Esto implica que todos los miembros de una LIS están capacitados para comunicarse vía ATM con todos los miembtros restantes del mismo LIS (la topología de CV está totalmente engranada). La comunicación a los hosts fuera del LIS local se proporciona vía router IP. Este router es un punto terminal ATM conectado a la red ATM que se configura como miembro de uno o más LISs. Esta configuración puede dar un número de LISs separados operando sobre la misma red ATM. Los hosts de diferentes subredes IP deben comunicarse vía router IP intermedio incluso aunque sea posible abrir un CV directo entre los dos miembros IP sobre la red ATM.
Encapsulación Multiprotocolo
Si se quiere usar más de un tipo de protocolo de red (IP, IPX, etc.) concurrentemente sobre una red física, se necesita un método de multiplexación de los diferentes protocolos. Esto se puede realizar en el caso de ATM por multiplexación basada en CV o encapsulación LLC. Si optamos por multiplexación basada en CV tenemos que tener un CV para cada protocolo diferente entre los dos hosts. La encapsulación LLC proporciona la función de multiplexado en la capa LLC y por tanto necesita un solo CV. TCP/IP utiliza, según el RFC 1577 y 1483, el segundo método porque este tipo de multiplexación estaba ya definido en el RFC 1042 para todos los otros tipos de LAN tales como Ethernet, token-ring y FDDI. Con esta definición IP usa ATM simplemente como sustituto de LAN. Todos los beneficios restantes que tiene que ofrecer ATM, tales como transporte de tráfico síncrono, etc, no se usan. Existe un grupo de trabajo (IETF) con la misión de mejorar la implementación y la interfaz con el foro de ATM a fin de representar los intereses de la comunidad de Internet para estándares futuros.
Para ser exactos, el PDU TCP/IP es encapsulado en una cabecera LLC IEEE 802.2 seguido de una cabecera SNAP IEEE 802.1a (Punto de Conexión a la Subred) y llevado con el campo de carga útil de un AAL5 CPCS-PDU (Subcapa de Convergencia de la Parte Común). El formato AAL5 CPCS-PDU se muestra en Figura - Formato AAL5 CPCS-PDU.
- Carga útil CPCS-PDU
- La carga útil CPCS-PDU se muestra en la Figura - Formato de carga útil CPCS-PDU para PDUs IP.
Pad- El campo Pad rellena el CDCS-PDU para ajustarlo exactamente a las celdas ATM.
CPCS-UU- El campo CPCS-UU (Identificación Usuario-a-Usuario) se usa para transferencia transparente CPCS de información usuario-a-usuario. Este campo no tiene función para la encapsulación y se le puede asignar cualquier valor.
CPI- El campo de CPI (Indicador de la Parte Común) alinea el CPCS-PDU trailer con 64 bits.
Longitud- El campo de Longitud indica la longitud, en bytes, del campo carga útil. El valor máximo es 65535 que es 64KB-1.
CRC- El campo CRC proteje todo el CPCS-PDU excepto a sí mismo.
El formato de carga útil para routed IP PDUs se muestra en la Figura - Formato de carga útil CPCS-PDU IP PDUs.
- IP PDU
- Normal IP datagram starting with the IP header.
- LLC
- 3-byte LLC header with the format DSAP-SSAP-Ctrl. For IP data it is set to 0xAA-AA-03 to indicate the presence of a SNAP header. The Ctrl field always has the value 0x03 specifying Unnumbered Information Commy PDU.
- OUI
- The 3-byte OUI (Organizationally Unique Identifier) identifies an organization which administers the meaning of the following 2-byte Protocol Identifier (PID). To specify an EtherType in PID the OUI has to be set to 0x00-00-00.
- PID
- The Protocol Identifier (PID) field specifies the protocol type of the following PDU. For IP datagrams the assigned EtherType or PID is 0x08-00.
The default MTU size for IP members in an ATM network is discussed in RFC 1626 y defined to be 9180 bytes. The LLC/SNAP header is 8 bytes; therefore, the default ATM AAL5 PDU size is 9188 bytes. The possible values can be between zero y 65535. You are allowed to change the MTU size but then all members of a LIS must be changed as well in order to have the same value. RFC 1755 recommends that all implementations should support MTU sizes up to y including 64KB.
La resolución de direcciones en una red ATM se define como una extensión del protocolo ARP y se describe en Resolución de Direcciones (ATMARP e InATMARP).
No existe una correspondencia entre IP broadcast or multicast addresses to ATM "broadcast" or multicast addresses available. Pero no hay restricciones en la transmición o recepción de datagramas IP especificando cualquiera de los cuatro formas de direccionar estándares de broadcast IP como se describen en el RFC 1122. Los miembros, después de recivir un broadcast IP o broadcast de subred IP para sus LIS, deben procesar el paquete como si estuviese direccionado a esa estación.
Emulación de una LAN ATM
Otro enfoque para proporcionar un camino migratorio hacia una red ATM nativa es la emulación de una LAN ATM. Esta emulación está todavía por construir por los grupos de trabajo ATM Forum. Para el enfoque IETF véase IP clásico sobre ATM. No existe acuerdo de realización de ATM Forum disponible para cubrir las LAN virtuales sobre ATM pero hay algunos acuerdos básicos sobre los diferentes propósitos realizados al ATM Forum. Las descripciones anteriores se basan en las propuestas por IBM.
El concepto de emulación de LAN ATM es construir un sistema tal que el software de aplicación de una estación de trabajo "piense" que es un miembro de una LAN real media compartida, como una token-ring por ejemplo. Este método maximiza la reutilización de software existente para LAN y reduce significantivamente el costo de migrar hacia ATM. In PC LAN environments for example the LAN emulation layer could be implemented under the NDIS/ODI-type interface. With such an implementation all the higher layer protocols, such as IP, IPX, NetBIOS y SNA for example, could be run over ATM networks without any change.
Referirse a la Figura - Ethernet y emulación de LAN Token-ring para la implementación de token-ring y Ethernet.
Capa de Emulación de LAN (Software de Estación de Trabajo)
Each workstation that performs the LE function needs to have software to provide the LE service. This software is called the LAN emulation layer (LE layer). It provides the interface to existing protocol support (such as IP, IPX, IEEE 802.2 LLC, NetBIOS, etc.) y emulates the functions of a real shared-medium LAN. This means that no changes are needed to existing LAN application software to use ATM services. The LE layer interfaces to the ATM network through a hardware ATM adapter.
The primary function of the LE layer is to transfer encapsulated LAN frames (arriving from higher layers) to their destination either directly (over a ``direct VC'') or through the LE server. This is done by using AAL5 services provided by ATM.
Each LE layer has one or more LAN addresses as well as an ATM address.
A separate instance (logical copy or LE client) of the LE layer is needed in each workstation for each different LAN or type of LAN to be supported. For example, if both token-ring y Ethernet LAN types are to be emulated, then you need two LE layers. In fact they will probably just be different threads within the same copy of the same code but they are logically separate LE layers. Separate LE layers would also be used if one workstation needed to be part of two different emulated token-ring LANs. Each separate LE layer needs a different MAC address but can share the same physical ATM connection (adapter).
2.13.3.2 LAN Emulation Server
The basic function of the LE server is to provide directory, multicast y address resolution services to the LE layers in the workstations. It also provides a connectionless data transfer service to the LE layers in the workstations if needed.
Each emulated LAN must have an LE server. It would be possible to have multiple LE servers sharing the same hardware y code (via multithreading) but the LE servers are logically separate entities. As for the LE layers, an emulated token-ring LAN cannot have members that are emulating an Ethernet LAN. Thus an instance of an LE server is dedicated to a single type of LAN emulation. The LE server may be physically internal to the ATM network or provided in an external device, but logically it is always an external function which simply uses the services provided by ATM to do its job.
CVs por defecto
Un CV por defecto es una conexión entre una capa LE en una estación de trabajo y el servidor LE. Estas conexiones pueden ser permanentes o conmutadas.
Todos los mensajes de control LE se transportan entre la capa LE y el servidor LE sobre el CV por defecto. Los marcos de datos encapsulados pueden también enviarse sobre CVs por defecto.
La presencia tanto del servidor LE como de los CVs por defecto es necesario para la capa LE.
CVs directos
Los CVs directos son conexiones entre capas LE en los sistemas terminales. Son siempre conmutados y se establecen por demanda. Si la red ATM no soporta conexiones conmutadas entonces no se puede tener CVs directos y todos los datos deben enviarse a través del servidor LE sobre CVs por defecto. Si no existe CV directo alguno por alguna razón entonces la transferencia de datos debe tener lugar a través del servidor LE (no hay otra forma).
Los CVs directos los establece la capa LE en la peticiones (el servidor no puede establecerlos ya que no existe una función de configuración de llamada a terceros en ATM). The ATM address of a destination LE layer is provided to a requesting LE layer by the LE server. Los CVs directos permanecen en su sitio hasta que uno de los socios de las capas LE decida finalizar la conexión (porque no existen más datos).
Inicialización
Durante la inicialización la capa LE (estación de trabajo) establece el CV con el servidor LE. Ésta también averigua su propia dirección ATM - esto es necesario si es después de establecer CVs directos.
Registro
En esta fase la capa LE (estación de trabajo) registra sus direcciones MAC con el servidor LE. Se pueden proporcionar otras cosas como requerimientos de filtrado (opcional).
Gestión y Resolución
Este es el método utilizado por las estaciones terminales ATM para establecer CVs directos con otras estaciones terminales (capas LE). Esta función incluye mecanismos para aprender la dirección ATM de una estación de destino, haciendo corresponder la dirección MAC con una dirección ATM, almacenando la correspondencia en una tabla y gestionan dicha tabla.
Para el servidor esta función proporciona los medios para suportar el uso de CVs directos por estaciones terminales. Esto incluye un mecanismo para hacer corresponder la dirección MAC de un sistema terminal con su dirección ATM, almacenando la información y proporcionándola a una estación terminal.
Esta estructura mantiene todas las funciones de una LAN y pueden soportar la mayoría de los protocolos de los niveles superiores. Reliance on the server for data transfer is minimized by using switched VCs for the transport of most bulk data.
IP clásico sobre ATM vs emulación de LAN
Estos dos enfoques para proporcionar una vía más fácil para migrar a ATM se han realizado con distintos objetivos.
IP clásico sobre ATM define un método de resolución de direcciones y encapsulación. La definición se hace únicamente para IP y no para usar con otros protocolos. Así que si se tiene aplicaciones que requieran otras pilas de protocolos (tales como IPX o SNA por ejemplo) entonces IP sobre ATM no proporcionará una solución completa. Por otra parte, si se tiene aplicaciones basadas sólo en TCP o UDP entonces esta puede ser la mejor solución, dado que esta adaptación especializada del protocolo IP a la arquitectura ATM probablemente produce menos costos que una solución global y por lo tanto es más eficiente. Otra de las ventajas de esta implementación es el uso de algunas funciones específicas de ATM, tales como grandes tamaños de MTU, etc.
El objetivo más importante de los enfoques de los foros sobre ATM es ejecutar el nivel 3 y protocolos superiores sobre la red ATM. Esto significa que los protocolos existentes, como TCP/IP, IPX, NetBIOS y SNA, por ejemplo, y sus aplicaciones pueden usar los beneficios de la rápida red ATM sin tener que modificar nada. El mapping para todos los protocolos ya está definido. El nivel de emulación de la LAN proporciona todos los servicios de una LAN clásica; por tanto, el nivel superior no sabe de la existencia de ATM. Esto se debe a una ventaja y a una desventaja porque conocer la red internamente podría utilizarse para proporcionar una implementación más efectiva.
En un futuro cercano, ambos enfoques se usarán dependiendo de los requerimientos particulares. Con el tiempo, cuando el mapping de las aplicaciones para ATM estén totalmente definida e implementada, el esquema de una implementación ATM dedicada se podrá usar.