 |
|
|
|
|
|
IP Message Fragmentation Process
(Page 3 of 4)
Fragmentation-Related IP Datagram Header Fields
When a sending device or router fragments a datagram, it must provide information that will allow the receiving device to be able to identify the fragments and reassemble them into the datagram that was originally sent. This information is recorded by the fragmenting device in a number of fields in the IP datagram header.
After fragmenting, this field indicates the length of each fragment, not the length of the overall message. Normally, the fragment size is selected to match the MTU value in bytes. However, fragments must have a length that is a multiple of 8, to allow proper offset specification (see below). The last fragment will usually be shorter than the others because it will contain a “leftover” piece, unless the message length happens to be an exact multiple of the fragment size.
To solve the “many jigsaw puzzles in a box” problem, a unique identifier is assigned to each message being fragmented. Consider this like writing a different number on the bottom of each piece of a jigsaw puzzle before tossing it into the box. This value is placed in the Identification field in the IP header of each fragment sent. The Identification field is 16 bits wide, so a total of 65,536 different identifiers can be used.
Obviously, we want to make sure that each message sent between the same source and destination that is being fragmented has a different identifier. The source can decide how it generates unique identifiers. This may be done through something as simple as a counter that is incremented each time a new set of fragments is created.
This 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.
This 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 65,528, just about the maximum size allowed for an IP datagram.
Let's take the same example from above. The first fragment would have a Fragment Offset of 0. The second would have an offset of 410 (3,280 divided by 8). The third would have an offset of 820 (6,560 divided by 8). 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.
|
| |||||||||||||||||||
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.