Table of Contents TCP Application Programming Interface
TCP/IP Tutorial and Technical Overview

2.13 Asynchronous Transfer Mode (ATM)

ATM-based networks are of increasing interest for both local and wide area applications. There are already some products available to build your physical ATM network. The ATM architecture is new and therefore different from the standard LAN architectures. For this reason, changes are required so that traditional LAN products will work in the ATM environment. In the case of TCP/IP the main change required is in the network interface to provide support for ATM.

There are several approaches already available, two of which are important to the transport of TCP/IP traffic. They are described in Classical IP over ATM and ATM LAN Emulation. They are also compared in Classical IP over ATM versus LAN Emulation.

2.13.1 Address Resolution (ATMARP and InATMARP)

The address resolution in an ATM logical IP subnet is done by the ATM Address Resolution Protocol (ATMARP) based on RFC 826 and the Inverse ATM Address Resolution Protocol (InATMARP) based on RFC 1293. ATMARP is the same protocol as the ARP protocol with extensions needed to support ARP in a unicast server ATM environment. InATMARP is the same protocol as the original InARP protocol but applied to ATM networks. Use of these protocols differs depending on whether PVCs or SVCs are used.

Both ATMARP and InATMARP are defined in RFC 1577, which is a proposed standard with a state of elective.

The encapsulation of ATMARP and InATMARP requests/replies is described in Classical IP over ATM. InATMARP

The ARP protocol is used to resolve a host's hardware address for a known IP address. The InATMARP protocol is used to resolve a host's IP address for a known hardware address. In a switched environment you first establish a VC (Virtual Connection) of either PVC (Permanent Virtual Connection) or SVC (Switched Virtual Connection) in order to communicate with another station. Therefore you know the exact hardware address of the partner by administration but the IP address is unknown. InATMARP provides dynamic address resolution. InARP uses the same frame format as the standard ARP but defines two new operation codes:

Please see ARP Packet Generation for more details.

Basic InATMARP operates essentially the same as ARP with the exception that InATMARP does not broadcast requests. This is because the hardware address of the destination station is already known. A requesting station simply formats a request by inserting its source hardware and IP address and the known target hardware address. It then zero fills the target protocol address field and sends it directly to the target station. For every InATMARP request, the receiving station formats a reply using the source address from the request as the target address of the reply. Both sides update their ARP tables. The hardware type value for ATM is 19 decimal and the EtherType field is set to 0x806, which indicates ARP according to RFC 1700. Address Resolution in a PVC Environment

In a PVC environment each station uses the InATMARP protocol to determine the IP addresses of all other connected stations. The resolution is done for those PVCs which are configured for LLC/SNAP encapsulation. It is the responsibility of each IP station supporting PVCs to revalidate ARP table entries as part of the aging process. Address Resolution in an SVC Environment

SVCs require support for ATMARP in the non-broadcast environment of ATM. To meet this need, a single ATMARP server must be located within the Logical IP Subnetwork (LIS) (see The Logical IP Subnetwork (LIS)). This server has authoritative responsibility for resolving the ATMARP requests of all IP members within the LIS. For an explanation of ATM terms please refer to Classical IP over ATM.

The server itself does not actively establish connections. It depends on the clients in the LIS to initiate the ATMARP registration procedure. An individual client connects to the ATMARP server using a point-to-point VC. The server, upon the completion of an ATM call/connection of a new VC specifying LLC/SNAP encapsulation, will transmit an InATMARP request to determine the IP address of the client. The InATMARP reply from the client contains the information necessary for the ATMARP server to build its ATMARP table cache. This table consists of:

This information is used to generate replies to the ATMARP requests it receives.

Note: The ATMARP server mechanism requires that each client be administratively configured with the ATM address of the ATMARP server.

ARP table add/update algorithm:
ATMARP table aging

ATMARP table entries are valid:

Prior to aging an ATMARP table entry, the ATMARP server generates an InARP_REQUEST on any open VC associated with that entry and decides what to do according to the following rules:

Therefore, if the client does not maintain an open VC to the server, the client must refresh its ATMARP information with the server at least once every 20 minutes. This is done by opening a VC to the server and exchanging the initial InATMARP packets.

The client handles the table updates according to the following:

As mentioned above, every ATM IP client which uses SVCs must know its ATMARP server's ATM address for the particular LIS. This address must be named at every client during customization. There is at present no "well-known" ATMARP server address defined.

2.13.2 Classical IP over ATM

The definitions for implementations of classical IP over ATM (Asynchronous Transfer Mode) are described in RFC 1577 which is a proposed standard with a status of elective according to RFC 1720 (STD 1). This RFC considers only the application of ATM as a direct replacement for the "wires", local LAN segments connecting IP end-stations ("members") and routers operating in the "classical" LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are not covered.

For ATM Forum's method of providing ATM migration please see ATM LAN Emulation.

Initial deployment of ATM provides a LAN segment replacement for:

This RFC also describes extensions to the ARP protocol (RFC 826) in order to work over ATM. This is discussed separately in Address Resolution (ATMARP and InATMARP).

First some ATM basics:

All information (voice, image, video, data , etc.) is transported through the network in very short (48 data bytes plus a 5-byte header) blocks called "cells".
Information flow is along paths (called "virtual channels") set up as a series of pointers through the network. The cell header contains an identifier that links the cell to the correct path that it will take towards its destination.

Cells on a particular virtual channel always follow the same path through the network and are delivered to the destination in the same order in which they were received.

Hardware-Based Switching
ATM is designed so that simple hardware-based logic elements may be employed at each node to perform the switching. On a link of 1 Gbps a new cell arrives and a cell is transmitted every .43 microseconds. There is not a lot of time to decide what to do with an arriving packet.
Virtual Connection VC
ATM provides a Virtual Connection switched environment. VC setup may be done on either a Permanent Virtual Connection (PVC) or a dynamic Switched Virtual Connection (SVC) basis. SVC call management is performed via implementations of the Q.93B protocol.
The only way 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 and vice versa. There are four different AAL types defined, AAL1, AAL2, AAL3/4 and AAL5. These AALs offer different services for higher layer protocols. Here are the characteristics of AAL5 which is used for TCP/IP: 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 and 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 and 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 and then the physical layer takes over to send the data to the ATM network. The cells are transported by the network and then received on the other side first by the physical layer, then processed by the ATM layer and 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).
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
There are currently no broadcast functions similar to LANs provided. But there is a multicast function available. The ATM term for multicast is "point-to-multipoint connection". The Logical IP Subnetwork (LIS)

The term LIS was introduced to map the logical IP structure to the ATM network. In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork (same IP network/subnet number and address mask). Each LIS operates and communicates independently of other LISs on the same ATM network. Hosts that are connected to an ATM network communicate directly to other hosts within the same LIS. This implies that all members of a LIS are able to communicate via ATM with all other members in the same LIS (VC topology is fully meshed). Communication to hosts outside of the local LIS is provided via an IP router. This router is an ATM endpoint attached to the ATM network that is configured as a member of one or more LISs. This configuration may result in a number of separate LISs operating over the same ATM network. Hosts of differing IP subnets must communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP members over the ATM network. Multiprotocol Encapsulation

If you want to use more than one type of network protocol (IP, IPX, etc.) concurrently over a physical network, you need a method of multiplexing the different protocols. This can be done in the case of ATM either by VC-based multiplexing or LLC encapsulation. If you choose VC-based multiplexing you have to have a VC for each different protocol between the two hosts. The LLC encapsulation provides the multiplexing function at the LLC layer and therefore needs only one VC. TCP/IP uses, according to RFC 1577 and 1483, the second method because this kind of multiplexing was already defined in RFC 1042 for all other LAN types such as Ethernet, token-ring and FDDI. With this definition IP uses ATM simply as a LAN replacement. All the other benefits ATM has to offer, such as transportation of isochronous traffic etc., are not used. There is an IETF working group with the mission of improving the IP implementation and to interface with the ATM Forum in order to represent the interests of the Internet community for future standards.

To be exact, the TCP/IP PDU is encapsulated in an IEEE 802.2 LLC header followed by an IEEE 802.1a SNAP header (SubNetwork Attachment Point) and carried within the payload field of an AAL5 CPCS-PDU (Common Part Convergence Sublayer). The AAL5 CPCS-PDU format is shown in Figure - AAL5 CPCS-PDU Format.

Figure: AAL5 CPCS-PDU Format

CPCS-PDU Payload
The CPCS-PDU payload is shown in Figure - CPCS-PDU Payload Format for IP PDUs.
The Pad field pads out the CDCS-PDU to fit exactly into the the ATM cells.
The CPCS-UU (User-to-User identification) field is used to transparently transfer CPCS user-to-user information. This field has no function for the encapsulation and can be set to any value.
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer with 64 bits.
The Length field indicates the length, in bytes, of the Payload field. The maximum value is 65535 which is 64KB - 1.
The CRC field protects the entire CPCS-PDU except the CRC field itself.

The payload format for routed IP PDUs is shown in Figure - CPCS-PDU Payload Format for IP PDUs.

Figure: CPCS-PDU Payload Format for IP PDUs

Normal IP datagram starting with the IP header.
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 Command PDU.
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.
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 and 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 and 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 and including 64KB.

The address resolution in an ATM network is defined as an extension of the ARP protocol and is described in Address Resolution (ATMARP and InATMARP).

There is no mapping from IP broadcast or multicast addresses to ATM "broadcast" or multicast addresses available. But there are no restrictions for transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in RFC 1122. Members, upon receiving an IP broadcast or IP subnet broadcast for their LIS, must process the packet as if addressed to that station. Implementations

The following implementations of classical IP over ATM according to RFC 1577 are available at the time of writing:

2.13.3 ATM LAN Emulation

Another approach to provide a migration path to a native ATM network is ATM LAN emulation. ATM LAN emulation is still under construction by ATM Forum working groups. For the IETF approach please see Classical IP over ATM. There is no ATM Forum implementation agreement available covering virtual LANs over ATM but there are some basic agreements on the different proposals made to the ATM Forum. The descriptions below are based on the IBM proposals.

The concept of ATM LAN emulation is to construct a system such that the workstation application software ``thinks'' it is a member of a real shared-medium LAN, such as a token-ring for example. This method maximizes the reuse of existing LAN software and significantly reduces the cost of migration to 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 and SNA for example, could be run over ATM networks without any change.

Refer to Figure - Ethernet and Token-ring LAN Emulation for the implementation of token-ring and Ethernet.

Figure: Ethernet and Token-ring LAN Emulation LAN Emulation Layer (Workstation Software)

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.) and 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 and 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). LAN Emulation Server

The basic function of the LE server is to provide directory, multicast and 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 and 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. Default VCs

A default VC is a connection between an LE layer in a workstation and the LE server. These connections may be permanent or switched.

All LE control messages are carried between the LE layer and the LE server on the default VC. Encapsulated data frames may also be sent on the default VC.

The presence of the LE server and the default VCs is necessary for the LE function to be performed. Direct VCs

Direct VCs are connections between LE layers in the end systems. They are always switched and set up on demand. If the ATM network does not support switched connections then you cannot have direct VCs and all the data must be sent through the LE server on default VCs. If there is no direct VC available for any reason then data transfer must take place through the LE server (there is no other way).

Direct VCs are set up on request by an LE layer (the server cannot set them up as there is no third party call setup function in ATM). The ATM address of a destination LE layer is provided to a requesting LE layer by the LE server. Direct VCs stay in place until one of the partner LE layers decides to end the connection (because there is no more data). Initialization

During initialization the LE layer (workstation) establishes the default VC with the LE server. It also discovers its own ATM address - this is needed if it is to later set up direct VCs. Registration

In this phase the LE layer (workstation) registers its MAC addresses with the LE server. Other things like filtering requirements (optional) may be provided. Management and Resolution

This is the method used by ATM end stations to set up direct VCs with other end stations (LE layers). This function includes mechanisms for learning the ATM address of a target station, mapping the MAC address to an ATM address, storing the mapping in a table and managing the table.

For the server this function provides the means for supporting the use of direct VCs by end stations. This includes a mechanism for mapping the MAC address of an end system to its ATM address, storing the information and providing it to a requesting end station.

This structure maintains full LAN function and can support most higher layer LAN protocols. Reliance on the server for data transfer is minimized by using switched VCs for the transport of most bulk data. Implementations

LAN emulation is provided by the following IBM products:

LAN Emulation software for OS/2, Ethernet and ATM Forum LAN Emulation Specification support is expected to follow during 1995.

2.13.4 Classical IP over ATM versus LAN Emulation

These two approaches to providing an easier way to migrate to ATM were made with different goals in mind.

Classical IP over ATM defines an encapsulation and address resolution method. The definitions are made for IP only and not for use with other protocols. So if you have applications requiring other protocol stacks (such as IPX or SNA for example) then IP over ATM will not provide a complete solution. On the other hand if you only have TCP or UDP-based applications then this might be the better solution, since this specialized adaptation of the IP protocol to the ATM architecture is likely to produce less overhead than a more global solution and therefore be more efficient. Another advantage of this implementation is the use of some ATM-specific functions, such as large MTU sizes, etc.

The major goal of the ATM Forum's approach is to run layer 3 and higher protocols unchanged over the ATM network. This means that existing protocols, such as TCP/IP, IPX, NetBIOS and SNA for example, and their applications can use the benefits of the fast ATM network without any changes. The mapping for all protocols is already defined. The LAN emulation layer provides all the services of a classic LAN; thus, the upper layer does not know of the existence of ATM. This is both an advantage and a disadvantage because the knowledge of the underlying network could be used to provide a more effective implementation.

In the near future both approaches will be used depending on the particular requirements. Over time, when the mapping of applications to ATM is fully defined and implemented, the scheme of a dedicated ATM implementation may be used.

Table of Contents TCP/IP and OSI