Two IP hosts on the same LAN communicating with each other must know each other's LAN address as well. If an algorithmic relation between the IP address and the LAN address of a host does not exist, another method must be found to determine the LAN address of the other party. The Address Resolution Protocol (ARP) was developed to do just that. ARP is a low-level protocol that hides the LAN address space for higher layers. The following quotation describes the layer-context ARP should be placed in: ``We consider it as part of the physical network system, and not as part of the internet protocols.'' [DC91]. Some might argue that ARP should be placed at the same level as IP, because it uses the LAN service to transport its packets. Both views have their merits, but in this thesis the ARP entity is shown as part of the Network Interface layer.
Ethernet is an example of a situation where the physical address is not algorithmically related to the IP address. The Ethernet physical address is assigned to the interface card in the factory and the IP number belonging to the interface is assigned by the network administrator where the card is used.
First the problem of address resolution within a LAN is shown for both a
broadcast LAN (like Ethernet) and a non-broadcast LAN. After that, a
situation is shown where two LANs are connected via an IP router. In the
figures, the ARP entity is shown as a ``layer'' on top of the LAN and
below the IP layer
.
Figure: Time-sequence example of ARP on a broadcast LAN
Ethernet is a good example of a
broadcast LAN, Figure 
shows a
time-sequence diagram of ARP on such a LAN.
Consider the situation where a machine X has to send a data-packet to
machine Y, but it only knows the IP address of machine Y
( 
), its own IP address ( 
) and Ethernet
address ( 
). X needs Y's Ethernet address
( 
) to transmit directly to Y. In order to find
, the IP layer will ask the the ARP entity on machine X
to resolve to an Ethernet address. The ARP entity sends
out an ARP request containing and the pair
( , ) to all machines using an
Ethernet broadcast method ( 
). All machines on the
network receive the broadcast ( 
), but only the
machine with as IP address recognizes the address as
its own and responds ( 
) with the pair
( , ) directly to .
After receiving the address-pair for machine Y ( 
), the
IP entity on machine X can now send directly to the IP entity on machine
Y using ( 
).
For reasons of efficiency, the ARP on each host uses a cache of the (LAN address,IP address) pairs. For more complete description of ARP, see [DC91]. The above example assumes that no entries exist in the ARP cache.
Ethernet is just one example of a LAN technology, with other kinds of LANs other implementations of ARP must be created to fit the particular network properties. As will be shown with ATM, this is not always trivial when a broadcast option is not available.
Figure: Time-sequence example of ARP on a non-broadcast LAN
Later ATM will be used as Network Interface layer. Currently ATM does not provide a broadcast option, it can therefore be used as an example for a LAN technology without broadcast option. When a broadcast option is not available, how can an IP address be resolved to a LAN address?
The solution used for Classical IP and ARP over ATM [ML94] is a
special ATMARP server
and a well known way to connect to it. The ATMARP server responds to every
ATMARP request on a Logical IP Subnet ( LIS) with the correct IP/ATM-address
combination or a negative response (to indicate that it has received the
request, but cannot resolve the address).
In Figure , the difference with ARP in a broadcast
network is clear: When the IP entity on host X wants to know the LAN
address of host Y, the ARP entity on host X contacts the ARP
server ( 
), assuming the ARP server knows the
IP/LAN address combination for host Y, the ARP server responds with host
Y's IP and LAN address pair ( 
). With the LAN
address of Y, host X can now send directly to Y
( 
). Although less `arrows' can be seen in
Figure than in Figure , remember that a
broadcast has the same ``cost'' on an Ethernet as a unicast.
As can be seen, an IP implementation on top of ATM must rely on a single entity on the network to resolve addresses. If the ARP server fails, the system fails, unless a backup system has been defined. ARP on Ethernet, on the other hand, only requires each machine to know its own IP address and LAN address. When a single machine breaks down, only that machine is affected (as far as address resolution is concerned).
Figure: Time-sequence example of ARP with a router and two LANs
In Figure two Ethernet LANs are shown, connected via an IP
router (R). Host X wants to transmit a packet to host Y (and X only
knows Y's IP address).
Each host has a routing table, which tells the IP entity whether an address is on the local network or behind a router. This is possible, because each IP address consists of a network ID and a host ID part. If the network ID of the destination IP address matches the local network's ID, the IP address is directly reachable.
If the address of Y is behind the router, host X sends the packet
directly to the router using its known LAN address
( ). The router's IP entity tries to resolve Y's
IP address on Ethernet 2. If the router's ARP entity for Ethernet 2
does not have Y's (IP address, LAN address) pair in the cache and it is
not listed in the routing table as being reachable through another
router, it must resolve the IP address of Y using the ARP service. The
ARP entity on the router does an ARP request on Ethernet 2 to resolve
Y's LAN address (this situation is shown in Figure ).
Resolving Y's IP address to a LAN address on Ethernet 2 is the same
procedure as shown in Figure . After Y's IP address is
resolved (labels 
), the router sends the
packet it received from host X to host Y using Y's LAN address
( 
).