Page 300 - DCAP403_Operating System

Unit 13: Case Study: Linux

Data Fragmentation Notes

Every network device has a maximum packet size and it cannot transmit or receive a data packet
bigger than this. The IP protocol allows for this and will fragment data into smaller units to

fit into the packet size that the network device can handle. The IP protocol header includes a

fragment field which contains a flag and the fragment offset.

When an IP packet is ready to be transmited, IP finds the network device to send the IP packet

out on. This device is found from the IP routing tables. Each device has a field describing its

maximum transfer unit (in bytes), this is the mtu field. If the device’s mtu is smaller than the

packet size of the IP packet that is waiting to be transmitted, then the IP packet must be broken
down into smaller (mtu sized) fragments. Each fragment is represented by an sk_buff; its IP
header marked to show that it is a fragment and what offset into the data this IP packet contains.
The last packet is marked as being the last IP fragment. If, during the fragmentation, IP cannot
allocate an sk_buff, the transmit will fail.

Receiving IP fragments is a little more difficult than sending them because the IP fragments can
be received in any order and they must all be received before they can be reassembled. Each time

an IP packet is received it is checked to see if it is an IP fragment. The first time that the fragment
of a message is received, IP creates a new ipq data structure, and this is linked into the ipqueue list
of IP fragments awaiting recombination. As more IP fragments are received, the correct ipq data
structure is found and a new ipfrag data structure is created to describe this fragment. Each ipq
data structure uniquely describes a fragmented IP receive frame with its source and destination

IP addresses, the upper layer protocol identifier and the identifier for this IP frame. When all of
the fragments have been received, they are combined into a single sk_buff and passed up to the
next protocol level to be processed. Each ipq contains a timer that is restarted each time a valid
fragment is received. If this timer expires, the ipq data structure and its ipfrag’s are dismantled
and the message is presumed to have been lost in transit. It is then up to the higher level protocols
to retransmit the message.

13.9.6 The Address Resolution Protocol (ARP)

The Address Resolution Protocol’s role is to provide translations of IP addresses into physical
hardware addresses such as ethernet addresses. IP needs this translation just before it passes the
data (in the form of an sk_buff) to the device driver for transmission.
It performs various checks to see if this device needs a hardware header and, if it does, if the
hardware header for the packet needs to be rebuilt. Linux caches hardware headers to avoid
frequent rebuilding of them. If the hardware header needs rebuilding, it calls the device specifi c
hardware header rebuilding routine. All ethernet devices use the same generic header rebuilding
routine which in turn uses the ARP services to translate the destination IP address into a physical
address.
The ARP protocol itself is very simple and consists of two message types, an ARP request and
an ARP reply. The ARP request contains the IP address that needs translating and the reply
(hopefully) contains the translated IP address, the hardware address. The ARP request is broadcast
to all hosts connected to the network, so, for an ethernet network, all of the machines connected
to the ethernet will see the ARP request. The machine that owns the IP address in the request will
respond to the ARP request with an ARP reply containing its own physical address.
The ARP protocol layer in Linux is built around a table of arp_table data structures which each
describe an IP to physical address translation. These entries are created as IP addresses need to

LOVELY PROFESSIONAL UNIVERSITY 293