ATM Specifications


This web-page will be updated in the near future to reflect a more realistic view of the current and future specifications according to the ITU, the IETF and the ATM-Forum.

Daniel Davids - 9 January 1997 (daniel.davids@cern.ch)



IP over ATM: A Framework Document (RFC-1932)

This memo summarizes some of the discussions of the IP over ATM working group over the last year. This summary is provided in the form of a framework which categorizes the various ATM subnet models and End-to-End models identified by the working group. The intent of this framework is to help partition the efforts of the working group to focus on smaller, more manageable aspects of IP over ATM. This is deemed necessary due to the number of ATM subnet types being discussed. The subnet models identified in this memo are:

The End-to-End models identified in this memo are:


Multiprotocol Encapsulation over AAL-5 (RFC-1483)

This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit.


Classical IP and ARP over ATM (RFC-1577)

This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and 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 beyond the scope of this paper.


ATM Signaling Support for IP over ATM (RFC-1755)

This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI) Specification Version 3.0. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities.

This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNI Specification Version 3.0. Unless explicitly stated, no distinction is made between the Private and Public UNI.


Default IP MTU for use over ATM AAL5 (RFC-1626)

Protocols in wide use throughout the Internet, such as the Network File System (NFS), currently use large frame sizes (e.g. 8 KB). Empirical evidence with various applications over the Transmission Control Protocol (TCP) indicates that larger Maximum Transmission Unit (MTU) sizes for the Internet Protocol (IP) tend to give better performance. Fragmentation of IP datagrams is known to be highly undesirable. It is desirable to reduce fragmentation in the network and thereby enhance performance by having the IP Maximum Transmission Unit (MTU) for AAL5 be reasonably large. NFS defaults to an 8192 byte frame size. Allowing for RPC/XDR, UDP, IP, and LLC headers, NFS would prefer a default MTU of at least 8300 octets. Routers can sometimes perform better with larger packet sizes because most of the performance costs in routers relate to "packets handled" rather than "bytes transferred". So there are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5.


Daniel Davids - 19 September 1994 (daniel.davids@cern.ch)