Hello Sandeep,

You are absolutely correct in what you wrote. However, I tend to believe that Daud's question was also concerned with a more obscure fact: who is using the ARP cache? Is it the IP driver or the Ethernet NIC driver?

From a pure theoretical and OSI-layered view, it's a kind of enigma: the IP should be agnostic about the data link layer and its specifics, and the Ethernet is not supposed to understand the IP specifics.

In reality, there must be an adaptation (or a convergence) sublayer present between the IP and the Ethernet driver that actually allows the IP to work over a specific data link layer technology, in this case, the Ethernet. The ARP belongs, in my opinion, to the category of L3 management protocols (I know that talking about the layer into which the ARP protocol belongs is starting a holy war - I don't plan to do anything similar here). The IP driver is the one which is using the ARP cache, and by means of the adaptation sublayer, it is able to also pass the L2 addressing information to the lower layer when sending a packet.

My two cents on this... Any other opinions are welcome!

Best regards,

Peter

Thanks both for your replies.

Dear Peter,

As far as i have understood from your reply, it is the duty of the Network Layer to provide the Destination MAC Address to the Data Link Layer?

Can you please explain it a bit further?

Best Regards,

Daud Parvez.

Hello Daud,

The OSI reference model is often explained in terms of individual layers being independent of each other. That is true to a certain point. If you think about it a little more you will find out that the layer N cannot be totally unaware of specifics of layer N-1 because it would prevent them from actually cooperating together.

The dilemma of ARP is a nice example. The IP itself is quite ignorant of any data link layer technology - it just does not care. However, once an IP driver sends an IP packet, it cannot be so ignorant anymore because the packet needs to be encapsulated in a frame with a proper addressing information. In order to make this IP-over-Ethernet thing work, there must be an element on the path between the network and data link layer that actually understands both IP and Ethernet specifics. Thus, in an IP driver implementation, there must a data link layer-specific part that adapts the IP to work over a particular link layer technology, in this case, the Ethernet.

You surely remember that the Ethernet itself is often depicted as consisting of two sublayers - the higher LLC (Logical Link Control), and the lower MAC (Media Access Control). The LLC is actually the functionality of Ethernet that allows us to multiplex several different payload types over Ethernet frames, carry user data, even make the Ethernet to provide connection-oriented data transfers (although I've never seen this feature implemented). However, there are various physical standards of the Ethernet available which is the reason why the MAC layer is present - to adapt the transmission of Ethernet frames over diverse media and access methods. In effect, there is a media-independent part, and a media-dependent part.

With the IP, although it may not be so visible in terms of layering, it's the same: there must be a data link layer-specific part in the actual IP driver, or at least the IP driver must have the ability to select an appropriate IP-to-L2 mapping database and pass the L2 address to the NIC driver (without actually understanding what the L2 information is - whether it is a MAC address, DLCI, VPI/VCI etc.). In essence, there must be a part of the IP driver adapted to particular data link technology. In the software engineering, this may be done nicely by utilizing a modular software design and software interfaces.

Best regards,

Peter