Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
IP Message Fragmentation Process
(Page 2 of 4)
The IP Fragmentation Process: An Example
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. Let's take the same example from the previous
topic, an IP message 12,000 bytes wide (including the 20-byte IP header)
that needs to be sent over a link with an MTU of 3,300. Here's a typical
method by which this fragmentation might be performed (you may find
the illustration in Figure 90
Figure 90: IPv4 Datagram Fragmentation Process
In this diagram, the MF and Fragment Offset fields of each fragment are shown for reference. The Data fields are shown to scale (the length of each is proportional to the number of bytes in the fragment.)
- Create First Fragment: The first
fragment is created by taking the first 3,300 bytes of the 12,000-byte
IP datagram. This includes the original header, which becomes the IP
header of the first fragment (with certain fields changed as described
below). So, 3,280 bytes of data are in the first fragment. This leaves
8,700 bytes to encapsulate (11,980 minus 3,280).
- Create Second Fragment: The
next 3,280 bytes of data are taken from the 8,700 bytes that remain
after the first fragment was built, and paired with a new header to
create fragment #2. This leaves 5,420 bytes.
- Create Third Fragment: The third
fragment is created from the next 3,280 bytes of data, with a 20-byte
header. This leaves 2,140 bytes of data.
- Create Fourth Fragment: The
remaining 2,140 bytes are placed into the fourth fragment, with a 20-byte
header of course.
I want to emphasize two important
points here. First, IP fragmentation does not work by
fully encapsulating the original IP message into the Data fields
of the fragments. If this were done, the first 20 bytes of the Data
field of the first fragment would contain the original IP header. This
technique is used by some other protocols, such as the PPP
Multilink Protocol, but not by IP. The
original IP header is transformed into the IP header of
the first fragment.
Second, note that the total number
of bytes transmitted increases: we are sending 12,060 bytes (3,300 times
three plus 2,160) instead of 12,000. The extra 60 bytes are from the
additional headers in the second, third and fourth fragments. (The increase
in size could theoretically be even larger if the headers contain options.)
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
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.