Each device on an IP internetwork must know the capacity of its immediate data link layer connection to other devices. This capacity is called the maximum transmission unit (MTU) of the network, also known as the maximum transfer unit.
If an IP layer receives a message to be sent across the internetwork, it looks at the size of the message and then computes how large the IP datagram would be after the addition of the 20 or more bytes needed for the IP header. If the total length is greater than the MTU of the underlying network, the IP layer will fragment the message into multiple IP fragments.
|KEY CONCEPT - The size of the largest IP datagram that can be transmitted over a physical network is called that network’s maximum transmission unit (MTU). If a datagram is passed from a network with a high MTU to one with a low MTU, it must be fragmented to fit the other network’s smaller MTU.|
Since some physical networks on the path between devices may have a smaller MTU than others, it may be necessary to fragment the datagram more than once. For example, suppose the source device wants to send an IP message 12000 bytes long. Its local connection has an MTU of 3300 bytes. It will need to divide this message into four fragments for transmission: three that are about 3300 bytes long and a fourth remnant about 2100 bytes long.
Again this IP fragments are need to pass over a hop between two routers where the physical network’s MTU is only 1300 bytes. In this case, each of the fragments will again need to be fragmented. The 3300-byte fragments will end up in three pieces each (two of about 1300 bytes and one of around 700 bytes), and the final 2100-byte fragment will become a 1300-byte and 800-byte fragment. So, instead of having four fragments, we will end up with eleven (3*3+1*2) fragments, as shown in Figure 1.
Figure 1 : IPv4 Datagram Fragmentation : This example illustrates a two-step fragmentation of a large IP datagram. The boxes represent datagrams or datagram fragments and are shown to scale. The original datagram is 12000 bytes, represented by the large, gray box. To transmit this data over the first local link, Device A splits it into four fragments, shown on the left. The first router must fragment each of these into smaller fragments to send them over the 1300-byte MTU link, as shown on the bottom. Note that the second router does not reassemble the 1300-byte fragments, even though its link to Device B has an MTU of 3300 bytes. Because intermediate devices do not perform reassembly; reassembly happens only at the message's ultimate destination.
The device performing the fragmentation follows a specific algorithm to divide the message into fragments for transmission. The exact implementation of the fragmentation process depends on the device. For example, consider an IP message 12000 bytes wide (including the 20-byte IP header) that needs to be sent over a link with an MTU of 3300 bytes. Figure 2 depicts a typical method by which this fragmentation might be performed.
The four fragments shown in Figure 2 are created as follows (Assume that each fragment's header length is 20 bytes, that means header without option field) :
|NOTES - There are two important points here. First, The original IP header is transformed into the IP header of the first fragment. Second 12060 bytes (3300*3+2160) are transmitted, instead of 12000 bytes. The extra 60 bytes are from the additional headers in the second, third, and fourth fragments.|
When a sending device or router fragments a datagram, it must provide information that will allow the receiving device to identify the fragments and reassemble them into the original datagram. This information is recorded by the fragmenting device in a number of fields in the IP datagram header :
Total Length - After fragmenting, the Total Length field indicates the length of each fragment, not the length of the overall message.
More Fragments - The More Fragments flag is set to a 1 for all fragments except the last one, which has it set to 0. When the fragment with a value of 0 in the More Fragments flag is seen, the destination knows it has received the last fragment of the message.
Fragment Offset - The Fragment Offset field solves the problem of sequencing fragments by indicating to the recipient device where in the overall message each particular fragment should be placed. The field is 13 bits wide, so the offset can be from 0 to 8191. Fragments are specified in units of 8 bytes, which is why fragment length must be a multiple of 8. Uncoincidentally, 8191*8 is 65528, just about the maximum size allowed for an IP datagram. In the example shown in Figure 2, the first fragment would have a Fragment Offset of 0, the second would have an offset of 410 (3280/8), the third would have an offset of 820 (6560/8), and the fourth would have an offset of 1230.
|KEY CONCEPT - When an MTU requirement forces a datagram to be fragmented, it is split into several smaller IP datagrams, each containing part of the original. The header of the original datagram is changed into the header of the first fragment, and new headers are created for the other fragments. Each is set to the same Identification value to mark them as part of the same original datagram. The Fragment Offset of each is set to the location where the fragment belongs in the original. The More Fragments field is set to 1 for all fragments but the last, to let the recipient know when it has received all the fragments.|
Routers are required to handle an MTU of at least 576 bytes. This value is specified in RFC 791; it was chosen to allow a data block of at least 512 bytes, plus room for the standard IP header and options. Since this is the minimum size specified in the IP standard, 576 bytes has become a common default MTU value used for IP datagrams. Even if a host is connected over a local network with an MTU larger than 576 bytes, it may choose to use an MTU value of 576 to ensure that no further fragmentation will be required by intermediate routers.
In IP version 4 (IPv4), fragmentation can be performed by a router between the source and destination of an IP datagram, but reassembly is done only by the destination device.
There are a number of reasons why the decision was made to implement IP reassembly this way. Perhaps the most important reason is that fragments can take different routes to get from the source to destination, so any given router may not see all the fragments in a message. Another reason is that if routers needed to worry about reassembling fragments, their complexity would increase. Finally, reassembly of a message requires that we wait for all fragments before sending on the reassembled message. Having routers do this would slow down routing. Since routers don’t reassemble messages, they can immediately forward all fragments on to the ultimate recipient.
The receiving device initializes a buffer where it can store the fragments of the message as they are received. The receiving device also sets up a timer for reassembly of the message.
Reassembly is complete when the entire buffer has been filled and the fragment with the More Fragments bit set to 0 is received, indicating that it is the last fragment of the datagram. The reassembled datagram is then processed in the same way as a normal, unfragmented datagram. On the other hand, if the timer for the reassembly expires with any of the fragments missing, the message cannot be reconstructed. The fragments are discarded, and an ICMP Time Exceeded message is generated.
IGNOU Assignment Solution
IGNOU Question Paper Solution
WHAT WE DO
Provide BCA, MCA Projects
Provide Assignment & Question Paper Solution