The components and operation of Classical IP and ARP over ATM are
specified in a group of IETF RFCs. These RFCs are created by the ION
(Internetworking Over NBMA
) working group of the IETF. In IETF RFC 1577 [ML94]
a specification is given of how to implement a Classical IP (i.e.
unicast only) and ARP service on top of ATM Adaptation Layer 5. RFC
1483 [JH93] defines how connectionless PDUs are transported over
AAL5. RFC 1755 [ASSI95] explains the ATM signalling involved in IP
over ATM operation. The Maximum Transmit Unit size (9180 octets) is
defined in RFC 1626 [RA94] with reasons why and a discussion about
negotiating a different MTU size on a SVCC. An overview of IP over ATM,
both in inter- and intra-subnet situations, is given in chapters 11 and
12 of [SM97]. Improvements and integration of later published,
related RFCs (like RFC 1626) is
currently being
developed.
When this document is approved as RFC, it will obsolete RFCs 1577 and
1626.
In this section, the term Logical IP Subnet (LIS) is introduced. A LIS is logically equivalent to a LAN as discussed in Chapter 2. All members of a LIS use the same ATMARP server and must be able to make a direct ATM connection with each other. In fact, the LIS is defined by the ATMARP server configured for a host. Multiple LISs may be defined on a single ATM network, each LIS has its own ATMARP server.
Figure: Classical IP and ARP over ATM (simplified protocol stack view)
In Figure 
, the modified layers of the TCP/IP protocol
stack are shown, as seen from the point of view of an IP implementation
on top of Ethernet (The ATM Bearer Service is shown as in
Figure on the right). RFC 1577 specifies how the IP
layer must be adapted to function on top of AAL5, using the
encapsulation methods defined in
RFC 1483 [JH93]. The LLC/SNAP encapsulation is explained in
Section . The ATMARP functionality is specified in RFC
1577, therefore it is drawn in that layer. The encapsulated
IP packets are carried in the Payload field of Common Part Convergence
Sublayer (CPCS) PDU of AAL5.
Ethernet ARP makes use of the broadcast medium to resolve IP addresses to Ethernet MAC addresses. In ATM, no broadcast is available, so another method must be used to resolve addresses. The larger part of RFC 1577 is dedicated to the definition of the ATMARP and InATMARP protocol.
The entity that implements the RFC 1483 specification is assumed to
take care of two functions; the encapsulation of IP packets using either
LLC/SNAP or ``null'' encapsulations, and the management of VCC's. The
first function, is discussed in more detail in Section
and it interacts with the AAL5 data transportation services.
The second function must keep track of open and closed VCCs for a
destination ATM address and open a closed (or new) VCC when a packet
must be sent over it. If VC multiplexing is used, the layer 3 protocol
type must be kept with the VCC administration, because if two different
protocols must reach the same ATM node, two VCCs must be used, one for
each layer 3 protocol.
Figure: Simplified time sequence example of (In)ATMARP operation
For the resolution of IP addresses to ATM addresses, a special ATMARP
server has been defined. All hosts register with this server at startup
by connecting to it (the used VCC may be permanent or switched). The server
responds with an InATMARP request on the same VCC. The host is
configured with its IP and ATM address(es) and it responds to the
InATMARP request by sending an InATMARP reply with that information to
the server, still using the same VCC. (See
Figure A).
Now consider two ATMARP clients (members of the same LIS), client X
wants to communicate with client Y and only Y's IP address is known to
X. The procedure to resolve Y's IP address to Y's ``hardware'' address
is very similar to the method used in Ethernet (see
Section ). Client X sends an ATMARP request with Y's IP
address to the ATMARP
server (we assume X and Y are already registered at the same ATMARP
server). The ATMARP server (not Y itself as in Ethernet) responds with
the pair of Y's IP and ATM address from its ATMARP resolution table. Now
X has Y's ATM address, which it remembers in its own ATMARP resolution
table. X can now setup an ATM connection to Y to transport the IP
packets. (This is shown in Figure B.)
Although RARP was not discussed in Chapter 2, InATMARP may be confused with Reverse ARP (RARP). RARP is used on Ethernet by hosts which are not configured with an IP address. By sending a RARP request with their MAC address, a special server can tell them their IP address in a RARP reply. InATMARP is derived from the InARP protocol defined in [BB92] for Frame Relay. It is used by a host to find out who is connecting to it. The host sends an InATMARP request over the opened connection to find out who is on the other side. The destination of an InATMARP message is implicit, because it uses an open connection.
Hosts in different LISs must communicate via an IP router, according to
RFC 1577. When hosts on these LISs can also make a direct ATM
connection, it would be much more efficient to by-pass the IP router
and use an ATM connection from source to destination. At this time, work is
in progress
to define a method to resolve, for example, IP addresses to ATM
addresses outside the LIS. The Next Hop Resolution Protocol
( NHRP) is a
generic protocol for IP on top of Non-Broadcast Multi-Access
( NBMA) network
technologies such as ATM or X.25.