Triangular routing

From HandWiki
Revision as of 05:42, 27 June 2023 by Steve2012 (talk | contribs) (correction)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Short description: Method for transmitting packets of data

Triangular routing is a method for transmitting packets of data in communications networks. It uses a form of routing that sends a packet to a proxy system before transmission to the intended destination. Triangular routing is a problem in mobile IP; however, it finds applications in other networking situations, for instance to avoid problems associated with network address translation (NAT), implemented for example by Skype.[citation needed]

               2) Datagram is intercepted   3) Datagram is
                  by home agent and            detunneled and
                  is tunneled to the           delivered to the
                  care-of address.             mobile node.

                     +-----+          +-------+         +------+
                     |home | =======> |foreign| ------> |mobile|
                     |agent|          | agent | <------ | node |
                     +-----+          +-------+         +------+
    1) Datagram to    /|\         /
       mobile node     |        /   4) For datagrams sent by the
       arrives on      |      /        mobile node, standard IP
       home network    |    /          routing delivers each to its
       via standard    |  |_           destination. In this figure,
       IP routing.   +----+            the foreign agent is the
                     |host|            mobile node's default router.
                     +----+

                    Figure 1:  Operation of Mobile IPv4
From RFC 5944.

Description

Notations Used

CH - Correspondent Host
MH - Mobile Host
HA - Home Agent
FA - Foreign Agent

Triangular Routing Problem

The problem in communication between a fixed host and a mobile host, such as a home computer and a smartphone, is that while the mobile host knows the fixed host's address, the fixed host does not know the mobile host's current address. Therefore, different routing must be used for the different directions.

In mobile IP, packets that are sent to a mobile host by the correspondent host are first routed to the mobile host's home agent and then forwarded to the mobile host at its current location by its home agent. However, packets that are sent from the mobile host should not be handled in this way.

Solution

For mobile IP, routing optimization is necessary because all packets sent to the mobile host (MH) shall pass through the home agent (HA) but the route may not be the best. After receiving the packets sent by the correspondent host (CH) to the MH, the HA notifies the CH of the binding information about the MH, i.e., the current foreign agent (FA) address of the MH, and the CH encapsulates the packets and establishes the tunnel to the FA for transparent transmission. The binding information is transferred via a definite port number. If the MH moves again, the new FA will transfer the updated binding information to the old FA to ensure that the packets are transferred to the new FA. And meanwhile, the HA gets the updated binding information so the subsequent packets will be transferred directly from the CH to the new FA. The mobile IP with route optimization sets high requirements on the CH. The CH shall have the ability to obtain the binding information, encapsulate the packets and establish the tunnel. Therefore, the CH protocol stack needs many modifications.

This may lead to problems when using services that do ingress filtering, since the source address on the packet will be the home address of the mobile host, not the care-of address assigned to the host on its guest network. To avoid this, many mobile IP implementations offer the option of tunneling packets from the mobile host through the home agent, too.

Unlike in mobile IPv4, mobile IPv6 avoids triangular routing and is therefore as efficient as native IPv6.[1]

References

  1. RFC 2002, Network Mobility (NEMO) Basic Protocol Support, M.V.Sai Manikanta, R. Wakikawa, A. Petrescu, P. Thubert (January 2005)