Loop Detection For Mobile Ip Home Agents
Abstract:
(57) Abstract: The present invention relates to a method and computer-readable medium for loop detection in data packet communication utilizing a tunnel in a network comprising a plurality of nodes. The method comprises the steps of, when a first node transmits a data packet, encoding an identification of the first node in at least two header fields of the data packet to be transmitted, and when the first node receives a data packet, analysing the at least two header fields of the data packet, deciding if a loop exists by determining if the data packet was sent by the first node itself, based on the analysis of the at least two header fields of the data packet.
Specification
Loop Detection for Mobile IP Home Agents
Background of the Invention Field of the Invention
Communications systems evolve more and more towards an Internet Protocol (IP)-based network. They typically consist of many interconnected networks, in which speech and data is transmitted from one terminal to another terminal in pieces, so-called packets. IP packets are routed to the destination by routers in a connection-less manner. Therefore, packets comprise IP header and payload information, whereby the header comprises among other things source and destination IP addresses.
For scalability reasons, an IP network uses a hierarchical addressing scheme. Hence, an IP address does not only identify the corresponding terminal, but additionally contains location information about this terminal. With additional information provided by routing protocols, routers in the network are able to identify the next router towards a specific destination.
One of the most commonly used tunneling mechanism is the IP(layer 3)-in-IP(layer 3) encapsulation, which refers to the process of encapsulating an IP-datagram with another IP header and may be used e.g. for Mobile IP. Mobile IPv6 - also denoted MIPvS - (see D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6". IETF RFC 3775, June 2004, available at http://www.ietf.org) is an IP-based mobility protocol that enables mobile nodes to move between subnets in a manner transparent for higher layers and applications, i.e. without breaking higher-layer connections. In other words, the mobile nodes remain reachable while moving around in the IPv6 internet network.
Usually, when a terminal powers on, it configures an IP address that is based on the IP address prefix of the access network. If a terminal is mobile, a so-called mobile node (MN). and moves between subnets with different IP prefix addresses, it must change its IP address to a topological correct address due to the hierarchical addressing scheme. However, since connections on higher-layers, such as TCP connections, are defined with the IP addresses (and ports) of the communicating nodes, the connection to the active IP sessions breaks if one of the nodes changes its IP address, e.g. due to movement. One
nnccihto nrntnr^nl to arlHrocc cairl nrnhlom ic tho ^^1P\/R nrntnrnl
The main principle of MIPv6 is that a mobile node is always identified by its Home Address (HoA), regardless of its topological location in the internet, while a Care-of Address (CoA) of the mobile node provides information about the current topological location of the mobile node.
In more detail, a mobile node has two IP addresses configured: a CarenDf Address and a Home Address. The mobile node's higher layers use the Home Address for communication with the communication partner (destination tenninal), from now on mainly called Correspondent Node (CN). This address does not change and serves the purpose of identification of the mobile node. Topologically, it belongs to the Home Network (HN) of the mobile node. In contrast, the Care-of Address changes on every movement resulting in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the mobile node is currently visiting. One out of a set of Home Agents (HA) located on the home link maintains a mapping of the mobile node's Care-of Address to the mobile node's Home Address and redirects incoming traffic for the mobile node to its current location. Reasons for deploying a set of home agents instead of a single home agent may be e.g. redundancy and load balancing.
Mobile IPv6 currently defines two modes of operation, one of which is bi-directional tunneling (Fig. 1). The other mode is the route optimization mode (Fig. 2), which will be discussed later. In using bi-directional tunneling, data packets sent by the correspondent node 101 and addressed to the home address of the mobile node 102 are intercepted by the home agent 111 in the home network 110. IP-in-IP encapsulation is required because each data packet that is intercepted needs to be resent over the network to the Care-of Address of the MN 102. Accordingly, each intercepted data packet is included as the payload in a new IP data packet addressed to the CoA of the MN 102 and tunneled to the MN 102, which is located at the foreign network 120. The start of the comesponding tunnel is the Home Agent 111, which carries out the encapsulation, and the end is the mobile node 102. It might also be possible that a local agent in the foreign network 120 receives messages on behalf of the mobile node, strips off the outer IP header and delivers the decapsulated data packet to the mobile node (not shown).
Data packets sent by the mobile node 102 are reverse tunneled to the home agent 111, whicn decapsulates tne packets and sends them to the correspondent node i01.
Reverse tunneling means that pacl
Documents
Application Documents
| # |
Name |
Date |
| 1 |
5637-CHENP-2009-AbandonedLetter.pdf |
2017-10-06 |
| 1 |
abs 5637-chenp-2009 abstract 23-09-2009.jpg |
2009-09-23 |
| 2 |
5637-CHENP-2009-FER.pdf |
2017-03-30 |
| 2 |
5637-chenp-2009 pct 23-09-2009.pdf |
2009-09-23 |
| 3 |
5637-chenp-2009 form-5 23-09-2009.pdf |
2009-09-23 |
| 3 |
5637-CHENP-2009 FORM-18 25-11-2010.pdf |
2010-11-25 |
| 4 |
5637-chenp-2009 form-3 23-09-2009.pdf |
2009-09-23 |
| 4 |
5637-CHENP-2009 FORM-3 25-01-2010.pdf |
2010-01-25 |
| 5 |
5637-chenp-2009 form-1 23-09-2009.pdf |
2009-09-23 |
| 5 |
5637-CHENP-2009 POWER OF ATTORNEY 25-01-2010.pdf |
2010-01-25 |
| 6 |
5637-chenp-2009 drawings 23-09-2009.pdf |
2009-09-23 |
| 6 |
5637-chenp-2009 correspondence others 23-09-2009.pdf |
2009-09-23 |
| 7 |
5637-chenp-2009 description(complete) 23-09-2009.pdf |
2009-09-23 |
| 7 |
5637-chenp-2009 abstract 23-09-2009.pdf |
2009-09-23 |
| 8 |
5637-chenp-2009 claims 23-09-2009.pdf |
2009-09-23 |
| 9 |
5637-chenp-2009 description(complete) 23-09-2009.pdf |
2009-09-23 |
| 9 |
5637-chenp-2009 abstract 23-09-2009.pdf |
2009-09-23 |
| 10 |
5637-chenp-2009 correspondence others 23-09-2009.pdf |
2009-09-23 |
| 10 |
5637-chenp-2009 drawings 23-09-2009.pdf |
2009-09-23 |
| 11 |
5637-chenp-2009 form-1 23-09-2009.pdf |
2009-09-23 |
| 11 |
5637-CHENP-2009 POWER OF ATTORNEY 25-01-2010.pdf |
2010-01-25 |
| 12 |
5637-chenp-2009 form-3 23-09-2009.pdf |
2009-09-23 |
| 12 |
5637-CHENP-2009 FORM-3 25-01-2010.pdf |
2010-01-25 |
| 13 |
5637-chenp-2009 form-5 23-09-2009.pdf |
2009-09-23 |
| 13 |
5637-CHENP-2009 FORM-18 25-11-2010.pdf |
2010-11-25 |
| 14 |
5637-CHENP-2009-FER.pdf |
2017-03-30 |
| 14 |
5637-chenp-2009 pct 23-09-2009.pdf |
2009-09-23 |
| 15 |
abs 5637-chenp-2009 abstract 23-09-2009.jpg |
2009-09-23 |
| 15 |
5637-CHENP-2009-AbandonedLetter.pdf |
2017-10-06 |
Search Strategy