WO2006129855A1

WO2006129855A1 - Method and apparatus for controlling packet forwarding

Info

Publication number: WO2006129855A1
Application number: PCT/JP2006/311358
Authority: WO
Inventors: Jun Hirano; Chan Wah Ng; Pek Yew Tan
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2005-05-31
Filing date: 2006-05-31
Publication date: 2006-12-07
Also published as: WO2006129855B1

Abstract

A technology is disclosed for eliminating inefficient and redundant routes occurred in case of forwarding a packet sent and received by a mobile node attached behind the mobile router, with a mobile router connected behind MAP (Mobility Anchor Point) which comprises the function of HMIP. According to this technology, MAP 120 delegates, for example, its own network prefix to the mobile router (MR) 140 which is connected under the control of the MAP. MR advertises this delegated prefix within the mobile network 104. The mobile node (MN) 150 attached to the mobile network configures its care-of address by using this prefix from MAP, and registers RCoA (Regional care-of address) and LcoA (Local care-of address) at MAP. MAP, receiving the packet addressed to RCoA of MN, checks that LCoA of MN includes the delegated prefix, and then tunnels the packet to the MR that is at the upper-level of MN.

Description

DESCRIPTION

METHOD AND APPARATUS FOR CONTROLLING PACKET FORWARDING

TECHNICAL FIELD

The present invention relates. to a packet forwarding control method and apparatus in packet- switched data communications networks such as an IP (Internet Protocol) network. More particularly, the present invention relates to a packet forwarding control method and apparatus to forward packets sent and received by nodes which use Mobile IP and HMIP

(Hierarchical Mobile IP) .

BACKGROUND ART

Many devices today communicate with each other using the IP .network. In order to provide mobility support to mobile devices, the Internet Engineering Task Force (IETF) has developed the "Mobility Support in IPv6" (see the following Non-patent Document 1) . In Mobile IP, each mobile node has a permanent home domain. When the mobile node is attached to its home network, it is assigned a primary global address known as a home address (HoA) .

When the mobile node is away, i.e. attached to some other foreign networks, it is usually assigned a temporary global address known as a care-of address

(CoA) . The idea of mobility support is such that the mobile node can be reached at the home-address even when it is attached to other foreign networks.

This is done in the Non-patent Document 1 with an introduction of an entity at the home network known as a home agent (HA) . Mobile nodes register their care-of addresses with the home agents using Binding Update (BU) messages. This allows the home agent to create a binding between the home address and care-of address of the mobile node. The home agent is responsible to intercept messages that are addressed to the mobile node's home address, and forward the packet to the mobile node's care-of address using packet encapsulation (i.e. putting one packet as the payload of a new packet, also known as packet tunneling) .

Although Mobile IP enables mobility support in the otherwise stationary addressing architecture of

IP infrastructure, there exist a few deficiencies.

One such deficiency is the need to send Binding

'Updates to home agents or correspondent nodes whenever the mobile device changes its point of attachment to the Internet. For a node with high mobility, such as a mobile device on a vehicle, the frequency at which the mobile node needs to send Binding Updates becomes prohibitively high.

For this reason, the IETF is currently developing a Hierarchical Mobile IPv6 Mobility Management Protocol (HMIP, see the following Non-patent Document 2) . The concept in HMIP is very similar to that contained in the following Patent Document 1. Here, an entity known as a Mobility Anchor Point (MAP) is defined, which handles a relatively large segment of an access network, allowing any mobile nodes roaming within the access network segment managed by a MAP to use the same care-of address. The trick here is for the mobile node to obtain a local care-of address

(LCoA) for its current point of attachment, and register this LCoA with the MAP. Upon registration, a regional care-of-address (RCoA) will be assigned to the mobile node, which the mobile node uses to send Binding Updates to its home agent. Thus, any packets sent to the home address of the mobile node will be encapsulated by its home agent, and forwarded to the RCoA of the mobile node. The MAP will intercept this packet, and tunnel it to the LCoA of the mobile node.

This greatly reduces the number of Binding Updates the mobile node needs to send to its home agent or correspondent nodes. As long as the mobile node moves within the access network segment managed by the same MAP, the mobile node will only change its LCoA while its RCoA remains unchanged. Thus, the mobile node only needs to notify the MAP of its LCoA, and need not send Binding Updates to its home agent or correspondent nodes. Only when the mobile node moves out of the access network segment managed by the original MAP, then a new RCoA needs to be assigned and the mobile node sends Binding Updates to its home agent or correspondent nodes. The following Patent Document 2 further enhances HMIP by providing a mechanism for mobile nodes or correspondent nodes to detect failures of the MAP. When this happens, Patent Document 2 provides for a back-off method for the ^■ mobile node to fall back to use its LCoA as the care-of address while locating a new MAP.

With the ever-increasing proliferation of wireless devices, it is foreseeable that a new class of mobility technology will emerge: network mobility, or NEMO, where a whole network of nodes changes its point of attachment in entirety. Extending the concept of mobility support for individual hosts to

'mobility support for a network of nodes, the objective of a network in motion solution is to provide a mechanism where nodes in a mobile network can be reached by their primary global addresses, no matter where on the Internet the mobile network is attached to.

The IETF is currently developing solution for network mobility as disclosed in the following Non- patent Document 2. Here, it is specified that the mobile router when sending BU to its home agent, will specify the network prefix which the nodes in the mobile network are using. These are specified using special options known as Network Prefix Options to be inserted into the BU. These allow the home agent to build a prefix-based routing table so that the home agent will forward any packets sent to destinations with these prefixes to the care-of address of the mobile router. This idea of using the bi-directional tunnel between the mobile router and its home agent is also described in the following Patent Document 3.

As with Mobile IP, network mobility also faces the same issue of frequent Binding Updates if the network is moving rapidly. It is unclear how HMIP can be integrated to the network mobility support solution. One obvious approach is for the mobile router to register its LCoA with the MAP, obtain an

^■RCoA from the MAP, and use this as the care-of address to send Binding Updates to its home agent. This scenario is depicted in Fig. 1, where the mobile router MR 140 is attached to an access router AR 130 that belongs to the access network 102 managed by the MAP 120. The mobile router MR 140 manages the mobile network 104 (in which, we show one mobile network node MN 150) . Home agent HA 110 is the home agent for the mobile router MR 140 and the network 100 is the global internet.

[Patent Document I]: Malki, K., Soliman, H., "Hierarchical Mobility Management For Wireless Networks", US Patent Application No 2001/0046223A1, Nov 2001.

[Patent Document 2]: Venkitaraman, N., "Method and Apparatus for Robust Local Mobility Management in a Mobile Network", US Patent Application No 2003/0185196A1, Oct 2003. [Patent Document 3]: Leung, K. K., "Mobile IP mobile router", US Patent 6,636,498, Oct 2003.

[Non-patent Document I]: Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force (IETF) Request For Comments (RFC) 3775, June 2004.

[Non-patent Document 2]: Soliman, H., et . al., "Hierarchical Mobile IPv6 Mobility Management (HMIPvβ)", IETF Internet Draft: draft-ietf-mipshop- hmipv6-04.txt, Work-in-progress, December 2004. [Non-patent Document 3]: Devarapalli, V., et. al., "NEMO Basic Support Protocol", IETF RFC 3963, January 2005.

This scenario might appear to work with HMIP and network mobility. However, when one considers the fact that the mobile network node MN 150 is also trying to use HMIP for its own local mobility management, a problem arises. This is better illustrated by an example depicted below.

Suppose the home agent 112 is the home agent for MN 150. Now, MN 150 would configure an LCoA from the prefix of the mobile network 104. It registers this LCoA with MAP 120, and obtains an RCoA from the MAP 120. When a correspondent node CN 160 sends a packet to the mobile node MN 150, the path the packet will take is depicted in Fig. 2. First, the packet addressed to the home address of MN 150 from CN 160 will take the path 210 to the home agent HA 112 of MN 150. HA 112 will then forward the packet to the RCoA of MN 150. This will result in the path 212 to MAP 120. MAP 120 intercepts the packet, and tunnels it to the LCoA of MN 150. However, since the LCoA is configured from the prefix of the mobile network 104, it will take the path 214 to the home agent HA 110 of the mobile router MR 140. HA 110 then forwards the packet to the RCoA of MR 140, taking the path 216 to MAP 120. MAP 120 tunnels the packet to the LCoA of MR 140 with the path 218. Finally, MR 140 encapsulates the packet, and forwards it to MN 150 (as shown by the path 220) .

From the above description, one can see the problem of simply combining HMIP with network mobility support. A packet addressed to a mobile node in a nested mobile network will take a long- winded path, possibly passing through the MAP multiple times. ^' Not only is this a waste of network ^' resources, it also greatly increases the packet latency. This can be unacceptable for real-time applications, ^" such as voice-over-IP or other multimedia sessions that are getting more and more popular.

DISCLOSURE OF THE INVENTION

It is thus an object of the present invention to eliminate inefficient and redundant routes (by which the packet latency is caused) occurred in case of, with the mobile router attached behind MAP, forwarding a packet sent and received by a mobile node attached behind the mobile router

In order to achieve the foregoing object, the present invention provides a method of controlling packet forwarding in a communication system, the communication system including a mobility anchor point which manages a hierarchical network, a mobile router which comprises a mobile network and a mobile node which is attached to the mobile network, the mobility anchor point storing address binding information on a binding between a local address for identifying location of a communication node within a network of the mobility anchor point and a global address used by the correspondent node to communicate with an outside of the network, the mobile node using an address configured based on a prefix advertised wi-thin the mobile network to communicate, wherein the mobile node is attached under the mobility anchor point's control, and wherein the mobility anchor point stores the address binding information on both the mobile router and the mobile node, the method comprising : a prefix grasping step in which the mobility anchor point grasps the prefix of the mobile network which the mobile router comprises behind; a prefix checking step in which the mobility anchor point checks if the local address of the mobile node includes the prefix grasped at the prefix ^•grasping step when the mobility anchor point receives a packet addressed to the global address of the mobile node; and a tunneling step in which the mobility anchor point tunnels the packet to the local address of the mobile router in case of finding the prefix matched with the local address of the mobile node at the prefix checking step. Moreover, in addition to the above-mentioned, the method of controlling packet forwarding of the present invention comprises a prefix delegating step in which the mobility anchor point delegates a prefix to the mobile router, the delegated prefix being owned by the mobility anchor point and available for the prefix of the mobile network by the mobile router.

Moreover, in addition to the above-mentioned, in the method of controlling packet forwarding of the present invention, the mobility anchor point inserts the prefix to delegate to the mobile router into a response message in response to registration of the address binding information by the mobile router.

Moreover, in addition to the above-mentioned, in the method of controlling packet forwarding of the present invention comprises a prefix advertising step in which the mobile router advertises, within the mobile network, the delegated prefix from the

'mobility anchor point with it obvious that the prefix is delegated from the mobility anchor point. Moreover, in addition to the above-mentioned, in the method of controlling packet forwarding of the present invention comprises a prefix notifying step in which the mobile router informs the mobility anchor point of the prefix of the mobile network.

Furthermore, in order to achieve the foregoing object, the present invention provides an apparatus for controlling packet forwarding arranged in a mobility anchor point which manages • a hierarchical network, comprising; a registration table storing means for storing address binding information on a binding between a local address for identifying location of a communication node within a network of the mobility anchor point and a global address used by the correspondent node to communicate with an outside of the network; a prefix storing means for storing a prefix of a mobile network behind a mobile router whose address binding information is registered at the registration table storing -means; a prefix checking means for checking if the local address of the mobile node includes the prefix stored in the prefix storing means when receiving a packet addressed to the global address of the mobile node whose address binding information is registered at the registration table storing means; and a tunneling means for tunneling the packet to the local address of the mobile router in case of finding the prefix matched with the local address of the mobile node by the prefix checking means.

The present invention comprising the foregoing construction has the advantage of eliminating inefficient and redundant routes (by which the packet latency is caused) occurred in case of, with the mobile router attached behind MAP, forwarding a packet sent and received by a mobile node attached behind the mobile router. Furthermore, the present invention has the advantage of reducing redundant processes by network elements or the packet latency.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a diagram showing an example of common network arrangement in the prior art and the embodiments of the present invention;

Fig. 2 is a diagram showing routes of packets sent from CN to MN in Fig. 1 when utilizing the prior art;

Fig. 3 is a diagram showing an example of architecture of MAP in the embodiments of the present invention;

Fig. 4 is a diagram showing an example of the Registration Table which MAP stores in the embodiments of the present invention; Fig. 5 is a diagram showing an example of the Prefix Table which MAP stores in the embodiments of the present invention;

Fig. 6 is a flow chart showing an example of an algorithm used when the routing unit of MAP performs the packet processing, in the embodiments of the present invention;

Fig. 7 is a diagram showing routes of packets sent from CN to MN in Fig. 1 in the embodiments of the present invention;

Fig. 8 is a diagram showing an example of a message format of the registration message in the embodiments of the present invention;

Fig. 9 is a diagram showing an example of a message format of the registration response message in the embodiments of the present . invention; and

Fig. 10 is a diagram showing an example of a message format of the router advertisement message in the embodiments of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

Description will be given below on the preferred aspects of the present invention referring to the drawings . The present invention describes a method employed by mobility anchor point (MAP) to eliminate routing inefficiency related to a nesting of mobile nodes within mobile networks. Its basic principle is for the MAP to be informed of the prefix associated with the mobile network behind a mobile router when the mobile router registers with the MAP. Any mobile nodes nested within that mobile network would configure an LCoA from this prefix.

Thus, when the MAP receives a packet addressed to the RCoA of the mobile node, it can check the prefix table and reali-ze that the mobile node has an LCoA within the prefix of the mobile network, and instead of tunneling the packet straight to the LCoA of the mobile node, it tunnels the packet to the mobile router. The reader is hereby noted that the term "mobile node" used throughout this specification should be taken to mean any mobile devices, including a host or a router, in accordance with the convention widely used in the industries and by persons skilled in the relevant art. The descriptions follow hereinafter referring the network diagram illustrated in Fig. 1. When MR 140 registers its LCoA, MAP 120 is also informed of the

^■prefix associated with the mobile network 104. Now, suppose MAP 120 receives a packet addressed to the RCoA of the mobile node MN 150. Ordinarily, MAP 120 would tunnel this packet to the LCoA of MN 150 as shown in Fig. 2. However, here, MAP 120 checks its prefix table and realizes that the LCoA of MN 150 has the same prefix as that of the mobile network 104. So, in addition to tunneling the packet to the LCoA of MN 150, MAP 120 further encapsulates this packet to the RCoA ^■ of MR 140. In this way, the routing, of the packet skips the paths 214 and 216 shown in Fig. 2, and is achieved the object of the present invention to provide a means of reducing the packet latency by minimizing the number ^' of times a packet needs to traverse a MAP regardless of the number of nesting of mobile networks the destination node is layered within.

To employ this, MAP 120 requires a functional architecture as shown in Fig. 3, comprising a Lower Network Interface 310, a Routing Unit 320, a Registration Unit 330, a Prefix Table 340 and a Registration Table 350.

The Lower Network Interface 310 is a functional block that represents all networking hardware, software and protocols that are necessary to allow the MAP 120 to communicate with other nodes on a

^•packet-switch data communications network. For instances, under the International Standards Organization's (ISO) Open System Interconnect .(OSI) 7-layers model, the Lower Network Interface 310 will encompass the Physical and Data Link Layers. Packets received from the network 100 or 102 will go through the packet path 362 or 364 to be processed by the Lower Network Interface 310. If the packet is intended for MAP 120 by the physical address, it will be passed to the Routing Unit 320 via the packet path 366.

The Routing Unit 320 handles all processing with respect to routing in the internetworking layer. Under the OSI model, it encompassed all functionalities of Network Layer. The Routing Unit 320 is responsible for forwarding packets to their next hops based on their final destinations. To do its work correctly, the Routing Unit 320 will need to consult the Registration Table 350 and Prefix Table 340 via the signal paths 376 and 374. This includes checking for the mapping of RCoA to LCoA from the Registration Table 350, and verifying of prefixes from the Prefix Table 340. In addition, if the received packet is actually a registration message from a mobile node, the message will be passed to the Registration Unit 330 for further processing via 'signal path 372.

The Registration Unit 330 is responsible for maintaining registrations of mobile nodes. It will create the mapping of RCoA to LCoA of a mobile node when a mobile node has made a registration and store the mapping into the Registration Table 350 via the signal path 378. In addition, when the mobile node is a mobile router, the Registration Unit 330 will also maintain the prefix information of the mobile network associated with the mobile router. The prefix information is stored in the Prefix Table 340 via the signal path 380.

Fig. 4 shows the contents of the Registration Table -350. It is basically a logical data structure where each row in the table corresponds to a mapping entry for one mobile node. Each entry comprises at least the RCoA field 352 storing the RCoA of the mobile node and the LCoA field 354 storing the LCoA of the mobile node.

.Fig. 5 shows the contents of the Prefix Table 340. It is basically a logical data structure where each row in the table corresponds to a prefix entry for a mobile network. Each entry comprises at least the Prefix field 342 storing the address prefix of the mobile network, the Prefix Length field 344 storing the number of significant bits of the address prefix,

'and the RCoA field 346' storing the RCoA of the mobile router associated to the mobile network. Although the Prefix Table 340 is described^' to contain the RCoA field 346, it should be obvious to 1

any person skilled in the art that one can use the LCoA instead of the RCoA in the Prefix Table 340. All that is needed is a form of identifier to link the entry in the Prefix Table 340 to a mapping in the' Registration Table 350. Furthermore, it should also be obvious to any person skilled in the art that the Prefix Length field 344 may be omitted from Prefix Table 340 if any other means exists for one to deduce the prefix length. One example may be some organization standardizing the number of significant bits in a prefix to be a constant number. Another example will be a particular pattern of bits in the prefix would indicate the length of the prefix as well. With th'e functional architecture of MAP 120 fully described, we can now explain how MAP 120 processes a received packet in order to achieve the object of the present invention. Fig. 6 shows the flowchart of the processing done by the Routing Unit 320 when MAP 120 receives a packet. In step 610, the packet is first checked if it is a registration message sent to MAP 120 by a mobile node. If so, step 620 will be taken where the registration message is passed to Registration Unit 330 for further processing. This includes the creation or modification of entries in the Registration Table 350, and, if the mobile node is a mobile router, creation or modification of prefix information in the Prefix Table 340.

If it is not a registration message, step 630 will be taken. Here, the destination address of the packet is checked against the Registration Table 350 to see if it matches the RCoA field 352 of any entry.

If a match is not found, the step 650 will be taken.

If a match is found, step 640 will be taken where the packet is encapsulated in a tunnel packet addressed to the address indicated by the LCoA field 354 of the matching entry in Registration Table 350.

In step 650, the destination address of the packet is checked against the prefix information of each entry in the Prefix Table 340 for a matched prefix according to the Prefix field 342 and Prefix

Length field 344. If there is no matching entry, step 660 will be taken where the packet is routed normally (as per normal Internet Protocol specification) . If a matching entry is found, the RCoA field 346 is noted from the matching entry as shown in step 670.

The address stored in the RCoA field 346 is used to ^■find a matching entry in the Registration Table 350 with the same RCoA field 352. The algorithm then reiterates back to step 640, where the packet is encapsulated in a tunnel addressed to the address indicated by the LCoA field 354 of the matching entry,

With this algorithm in place, the object of the present invention will be achieved. We illustrate this by considering an example as depicted in Fig. 1. - When the mobile router 140 sends a registration message to MAP 120, this registration message is processed as per step 620, resulting in the adding of an entry mapping the RCoA of MR 140 to the LCoA of MR

140 in the . Registration Table 350 and an entry containing the prefix information of the mobile network 104 in Prefix Table 340. Similarly, when the mobile node MN 150 sends a registration message to MAP 120, this registration message is processed as per step .620, resulting in the adding of an entry mapping the RCoA of MN 150 to the LCoA of MN 150 in the Registration Table 350.

With the registrations made, Fig. 7 shows the path taken by a packet sent from the correspondent node CN 160 to the mobile node MN 150. First, the packet addressed to the home address of MN 150 from

CN 160 will take the path 710 to the home' agent HA

112 of MN 150. HA 112 will then forward the packet

^•to the RCoA of MN 150. This will result in the path

712 to the MAP 120. MAP 120 intercepts the packet, and finds a matching entry in its Registration Table 340.' So, as per step 640, the packet is encapsulated to the LCoA of MN 150.

However, in step 650, MAP 120 locates an entry in its Prefix Table 340 that matches the LCoA of MN 150. Thus, as per step 670, the packet will again encapsulated and forwarded to the LCoA of mobile router MR 140. This is the resulting path 714. Finally, MR 140 decapsulates the packet, and forwards it to MN 150 via the path 716.

The above embodiment of the present invention clearly illustrates that' the object of the present invention is realized. .There remains, however, one problem of how the prefix information of the mobile network 104. associated with the mobile router 140 is conveyed to MAP 120. In one preferred embodiment to realize this, the prefix information is specified the same way it is done in [Non-Patent Document 3] . The mobile router 140 will include one or more Network Prefix options in the registration message it sends to MAP 120, thereby informing MAP 120 about the prefix of its mobile network 104. This method, though simple and elegant, requires MAP 120 to trust the information

'conveyed in the registration message. The approach in which MAP 120 establishes the trust in the prefix information claimed by the mobile router MR 140 is beyond the scope and ambit of the present invention. In yet another preferred approach, such a trust is not necessary. Here, MAP 120 will delegate a network prefix owned by MAP 120 itself to the mobile router MR 140. Mobile router 140 will then advertise this delegated prefix to its mobile network 104 for use with MAP 120. This will cause MN 150 to configure an LCoA that is based on the delegated prefix if MN 150 wants to use the services provided by MAP 120. Since this network prefix is delegated by MAP 120 itself, there is no question of a trust relationship being necessary.

Fig. 8 shows the registration message 800 sent to MAP 120 by the mobile router MR 140.- This is basically a Binding Update message as specified by Mobile IPv6. Note that not all contents of the packet are shown in Fig 8. A person skilled in the art will recognize some other essential fields that are not relevant to the operation of the present invention, and these fields are thus omitted. The source address field 802 contains the LCoA of the mobile router MR 140. The destination address field 804 contains the address of MAP 120^'. The home

'address option HAO field 810 contains the RCoA of the mobile router MR 140. As a Binding Update message, the registration message 800 will contain a mobility header 820, with the type field 822 indicating this message as a binding update. The length field 824 indicates the length of the mobility header 820 in units of 8 octets. The sequence number field 826 contains a number for the receiver (i.e MAP 120) to sequence the binding update message. The lifetime field 828 contains the number of time units remaining before the binding must be considered expired. One time unit is, for example, 4 seconds. The A-flag 830 is set to indicate that mobile router MR 140 requires MAP 120 to reply with a Binding Acknowledgement message. The H-flag 832 is not set since this is not a home registration. The M-flag 834 is set since this is a registration to MAP, The R-flag 836 is set to indicate that the sender (i.e. MR 140) is a mobile router.

The setting of the M-flag 834 and R-flag 836 in the registration message 800 indicates to MAP 120 that the sender (i.e. mobile router MR 140) is requesting for prefix delegation. MAP 120 will then reply with a registration response containing information of the delegated prefix. Fig. 9 shows the packet format of the registration response 900. This is basically a Binding Acknowledgement message as specified by Mobile IPv6. Note that not all contents of the packet are shown in Fig 9. A person skilled in the art will recognize some other essential fields that are not relevant to the operation of the present invention, and these fields are thus omitted. In Fig. 9, the source address field 902 contains the address of MAP 120,, and the destination address field 904 contains the LCoA of the mobile router MR 140. The type 2 routing header RH2 field 910 contains the RCoA of the mobile router MR 140. As a Binding Acknowledgement message, the registration response 900 will contain a mobility header 920, with the type field 922 indicating this message as a binding acknowledgement. The length field 924 indicates the length of the mobility header 920 in units of 8 octets. The sequence number field 926 contains the same sequence number received in the registration message. The lifetime field 928 contains the number of time units remaining before the binding must be considered expired. One time unit is,^' for example, 4 seconds.

The status field 930 contains a code to indicate the success or failure of the registration. If the

'registration is successful and MAP 120 is willing to delegate a prefix to the mobile router MR 140, the registration response 900 will contain one or more delegated prefix option 940. The option type field 942 will indicate this option as the delegated prefix option. The prefix field 944 will contain the delegated prefix, and the prefix length field 946 will contain the length of the delegated prefix. Once the mobile router 140 has been delegated with a prefix from MAP 120, it can advertise this to its mobile network 104 so that mobile nodes in the mobile network 102 can configure their LCoA based on this delegated prefix, instead of the original mobile network prefix. Fig. 10 shows the message format of the router advertisement 1000 sent by mobile router MR 140 to nodes in its mobile network 104. A person skilled in the art will recognize some other essential fields that are not relevant to the operation of the present invention, and these fields are thus omitted.

In Fig. 10, the source address field 1002 contains the address of the mobile router MR 140, and the destination address field 1004 contains the address of the recipients, usually a broadcast address .

As a router advertisement, the message 1000 will 'contain an ICMP (Internet Control Message Protocol) header 1010, with the type field 1012 and code field 1014 indicating this message as a router advertisement. The router lifetime field 1016 indicates number of seconds the mobile router MR 140 can serve as a default router. The router advertisement 1000 contains several options, including one or more prefix information options 1020, one or more MAP options 1030, and one or more MAP prefix options 1040.

The prefix information option 1020 is used to convey the normal prefix used by the mobile network 104. The option type field 1022 indicates this option as the prefix information option. The prefix field 1024 contains the original mobile network prefix and the prefix length field 1026 contains the length of the original mobile network prefix. The lifetime field 1028 contains the number of seconds remaining while the prefix is still valid.

The MAP option 1030, as defined in [Non-Patent Document 2], is used to convey information about the MAP. The type field 1032 indicates this option as a MAP option. The global address field 1034 contains the address of the MAP. The lifetime field 1036 contains the number of seconds remaining while the MAP is still functioning as a MAP.

The MAP prefix option 1040 is used to convey the prefix delegated to mobile router MR 140 by the MAP. The option type field 1042 indicates this option as the MAP prefix option. The prefix field 1044 contains the delegated prefix and the prefix length field 1046 contains the length of the delegated prefix. The lifetime field 1048 contains the number of seconds remaining while the delegated prefix is still- valid.

If multiple MAP options 1030 and MAP prefix options 1040 are present, these options must be ordered in such a way within the ICMP header 1010 so that a MAP prefix option 1040 always contain the prefix delegated by the MAP whose address is contained by an immediately preceding MAP option 1030.

Separating the delegated prefix from the normal prefix of the mobile network 104 by using separate

MAP prefix option 1040 and prefix information option 1020 prevents nodes that do not • use mobility protocols from accidentally configuring their addresses from the delegated prefix. This delegated prefix will change once the mobile network 104 moves out of the access network segment 102 managed by MAP 120. If nodes that do not use mobility protocols configure their addresses from the delegated prefix, they would need to change their addresses whenever

^'the mobile network 104 switches a MAP domain. For long-term transport session that relies on using the same address, this constant changing of addresses can be disruptive. The present invention describes a MAP 120 of enhanced functionality to extend the operations of HMIP to network mobility support. Since this can be considered as an extra feature, it is necessary to provide a means for mobile nodes to detect the capabilities (functionality according to the present invention) of a MAP when the mobile nodes are registering with the MAP. As the extra features disclosed in the present invention will only impact mobile routers, we focus our attention to registrations made by mobile routers.

A mobile router can detect if the MAP supports the new functionality with various different approaches. One' approach is for the access routers AR 130, 132 and 134 in the access network segment 102 to add a special option when advertising the services of MAP 120. This special option will indicate to the recipients that the MAP advertised supports the new functionality. Another approach is - for the mobile router to send a registration message with prefix information to the MAP, and requiring the MAP to response with a registration response that have a different status code contained in status field 930 that indicates the registration of the prefix information is successful on top of the registration of the mapping between LCoA and RCoA.

Yet another approach is for the mobile router to request the MAP to delegate a prefix when registering with the MAP. If the delegated prefix is contained in the registration response, the MAP supports the new functionality. If no delegated prefix is included, the MAP does not support the new functionality.

Although the invention has been herein shown and described in what is conceived to be the most practical and preferred embodiment, it will be appreciated by those skilled in the art that various modifications may be made in details of design and parameters without departing from the scope and ambit of the invention. For example, when describing the registration message 800 in one preferred embodiment, it is specified that the setting of the R-flag 836 and M-flag 834 as an indication to the MAP 120 that the sender is requesting of a delegated prefix. A person skilled in the art can easily note that the same effect could have alternatively been achieved by using a separate field in the registration message to indicate the request for a prefix to be delegated.

INDUSTRIAL APPLICABILITY

The present invention has the advantage of eliminating inefficient and redundant routes occurred in case of, with the mobile router attached behind MAP, forwarding a packet sent and received by a mobile node attached behind the mobile router. The present invention can be applied to the communication technology of the packet-switched data communication network ■ or the packet forwarding • and processing technology.

Claims

1. A method of controlling packet forwarding in a communication system, the communication system including a mobility anchor point which manages a hierarchical network, a mobile router which comprises a mobile network and a mobile node which is attached to the mobile network, the mobility anchor point storing address binding information on a binding between a local address for identifying location of a communication node within a network of the mobility anchor point and a global address used by the correspondent node to communicate with an outside of the network, the mobile node using an address configured based on a prefix advertised within the mobile network to communicate, wherein the mobile node is attached under the mobility anchor point's control, and wherein the mobility anchor point stores the address binding information on both the mobile router and the mobile node, the method comprising: a prefix grasping step in which the mobility anchor point grasps the prefix of the mobile network which the mobile router comprises behind; a prefix checking step in which the mobility anchor point checks if the local address of the mobile node includes the prefix grasped at the prefix grasping step when the mobility anchor point receives a packet addressed to the global address of the mobile node; and a tunneling step in which the mobility anchor point tunnels the packet to the local address of the mobile router in case of finding the prefix matched with the local address of the mobile node at the prefix checking step.

2. The method of controlling packet forwarding according to claim 1, comprising a prefix delegating step in which the mobility anchor point delegates a prefix to the mobile router, the delegated prefix being owned by the mobility anchor point and available for the prefix of the mobile network by the mobile router.

3. The method of controlling packet forwarding according to claim 2, wherein the mobility anchor point inserts the prefix to delegate to the mobile router into a response message in response to registration of the address binding information by

^'the mobile router.

4. The method of controlling packet forwarding according to claim 2, comprising a prefix advertising step in which the mobile router advertises, within the mobile network, the delegated prefix from the mobility anchor point with it obvious that the prefix is delegated from the mobility anchor point.

5. The method of controlling packet forwarding according to claim 1, comprising a prefix notifying step in which the mobile router informs the mobility anchor point of the prefix of the mobile network.

6. An apparatus for controlling packet forwarding arranged in a mobility anchor point which manages a hierarchical network, comprising; a registration table storing means for storing address binding information on a- binding between a local address for identifying location of a communication node within a network of the mobility anchor point and a global address used by the correspondent node to communicate with an outside of the network; a prefix storing means for storing a prefix of a mobile network behind a mobile router whose address 'binding information is registered at the registration table storing means; a prefix checking means for checking if the local address of the mobile node includes the prefix stored in the prefix storing means when receiving a packet addressed to the global address of the mobile node whose address binding information is registered at the registration table storing means; and a tunneling means for tunneling the packet to the local address of the mobile router in case of finding the prefix matched with the local address of the mobile node by the prefix checking means.