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.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)
      9  TCP/IP Internet Layer (OSI Network Layer) Protocols
           9  Internet Protocol (IP/IPv4, IPng/IPv6) and IP-Related Protocols (IP NAT, IPSec, Mobile IP)
                9  Internet Protocol Version 4 (IP, IPv4)
                     9  IP Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly

Previous Topic/Section
IP Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly
Previous Page
Pages in Current Topic/Section
1
234
Next Page
IP Message Fragmentation Process
Next Topic/Section

IP Datagram Size, the Maximum Transmission Unit (MTU), and Fragmentation Overview
(Page 1 of 4)

As the core network layer protocol of the TCP/IP protocol suite, IP is designed to implement potentially large internetworks of devices. When we work with IP we get used to the concept of hosts being able to send information back and forth even though they may be quite far away and the data may need to travel across many devices between them. Even though we can usually consider the TCP/IP internet to be like a large, abstract “virtual network” of devices, we must always remember that underneath the network layer, data always travels across one or more physical networks. The implementation of the Internet Protocol must take this reality into account as well.

In order to send messages using IP we encapsulate the higher-layer data into IP datagrams. These datagrams must then be sent down to the data link layer, where they are further encapsulated into the frames of whatever technology is going to be used to physically convey them, either directly to their destination, or indirectly to the next intermediate step in their journey to their intended recipient. The data link layer implementation puts the entire IP datagram into the data portion (the payload) of its frame format, just as IP puts transport layer messages, transport headers and all, into its IP Data field. This immediately presents us with a potential issue: matching the size of the IP datagram to the size of the underlying data link layer frame size.

Matching IP Datagram Size to Underlying Network Frame Size

The underlying network that a device uses to connect to other devices could be LAN connection like Ethernet or Token Ring, a wireless LAN link such as 802.11, or a dialup, DSL, T-1 or other WAN connection. Each physical network will generally use its own frame format, and each format has a limit on how much data can be sent in a single frame. If the IP datagram is too large for the data link layer frame format's payload section, we have a problem!

For example, consider an FDDI. The maximum size of the data field in FDDI is around 4,470, depending on whether or not SNAP is used. This means FDDI can handle an IP datagram of up to 4,470 bytes. In contrast, a regular Ethernet frame uses a frame format that limits the size of the payload it sends to 1,500 bytes. This means Ethernet can't deal with IP datagrams greater than 1,500 bytes in size.

Now, remember that in sending a datagram across an internetwork, it may pass across more than one physical network. To access a site on the Internet, for example, we typically send a request through our local router, which then connects to other routers that eventually relay the request to the Internet site. Each hop as the datagram is forwarded may use a different physical network, with a different maximum underlying frame size.

The whole idea behind a network layer protocol is to implement this concept of a “virtual network” where devices talk even though they are far away. This means that higher layers shouldn't need to worry about details like the size limits of underlying data link layer technologies. However, someone has to worry about it. This task falls to the Internet Protocol.


Previous Topic/Section
IP Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly
Previous Page
Pages in Current Topic/Section
1
234
Next Page
IP Message Fragmentation Process
Next Topic/Section

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!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.