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!

Searchable, convenient, complete TCP/IP information.
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 Mobility Support (Mobile IP)

Previous Topic/Section
Mobile IP and TCP/IP Address Resolution Protocol (ARP) Operation
Previous Page
Pages in Current Topic/Section
1
2
Next Page
Mobile IP Security Considerations
Next Topic/Section

Mobile IP Efficiency Issues
(Page 1 of 2)

Having the home agent forward all datagrams to the mobile node wherever it may be is a convenient solution to mobility, but is also a rather inefficient one. Since every datagram must be sent first to the home network and then be forwarded to the mobile node, datagrams are going to travel over some part of the internetwork twice. The degree of inefficiency represented by forwarding can be significant, and may lead to problems with certain applications.

To see what the problem is, let's consider a traveling mobile node M and a regular device that wants to send to it, device A. The degree of the inefficiency of Mobile IP is a function of the internetwork distance between device A and M's home network, compared to the internetwork distance between device A and M's current network. By distance here, I mean the term as it is used in determining routes on an internetwork; two devices are “closer” when it takes less time and/or fewer hops to communicate between them, and “farther” when it takes more. (I use geography in my examples below to represent this notion of distance, but remember that geographical distance is only one factor in internetwork distance.)

The Impact on Efficiency of Sending Device Location

Let's consider the case where mobile node M is on a foreign network quite far from home, and a sending device, device A, wants to send a datagram using node M’s home IP address. Suppose the home network is in London and the device is again in Tokyo, Japan. The following examples are arranged in order of increasing inefficiency of Mobile IP, compared to the alternative of having the mobile node just get a new temporary IP address on the foreign network and not use Mobile IP:

  • Sending Device On Home Network: In this situation, device A will send a datagram that is immediately intercepted by the home agent on the home network and forwarded to the mobile node. There is really no inefficiency here at all (except for overhead for encapsulation and such) because even if A sent directly to the mobile node with a new foreign address, it would probably be routed through the home agent router anyway.

  • Sending Device On Network Close To Home Network: Here, let's say a device in Paris, France wants to send to the mobile node. The datagram goes from Paris to London and then to Tokyo. That's not too bad.

  • Sending Device On Network Close To Foreign Network: Now, suppose the sending device is in Taipei, Taiwan. In this situation, Mobile IP becomes quite inefficient. The datagram must be sent from Taipei all the way to London, and then all the way back to Tokyo.

  • Sending Device On Foreign Network: The greatest inefficiency results when the sending device is actually on the foreign network that the mobile node is visiting. If device A is on the mobile node's current network in Tokyo, it must send all the way to London and then have the result forwarded all the way back again to Tokyo. Without Mobile IP, all we would need to do is use ARP and then deliver directly at layer two without routing needed at all! This scenario is illustrated in Figure 136.

    Figure 136: A Mobile IP Inefficiency “Worst Case Scenario”

    This diagram show the worst possible case of Mobile IP inefficiency: when a device on the foreign network where the mobile is located tries to send to it. The sender here, 210.4.79.11, uses the mobile node’s home address, so the transmission must be routed all the way back to London and then forwarded back to Tokyo, even though the two devices might be sitting on the same desk!

     


Unfortunately, the “worst case scenario” outlined in the last bullet point is one that occurs quite often. It's common for a mobile device to connect with a foreign network specifically to communicate with the hosts on that network


Previous Topic/Section
Mobile IP and TCP/IP Address Resolution Protocol (ARP) Operation
Previous Page
Pages in Current Topic/Section
1
2
Next Page
Mobile IP Security Considerations
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.