The Internet is becoming more and more popular, with access to the Internet being provided via computer networks and communication networks. The standard communication mechanism that communication units use to access the Internet is the well-known Internet Protocol (IP) version 4 and version 6.
Indeed, users increasingly wish to access the Internet whilst on the move via their mobile communication device(s). These devices are termed mobile nodes in IP-parlance. Different types of mobile nodes may be employed for this purpose, for example, a portable personal computer (PC), a mobile telephone or a personal digital assistant (PDA) with wireless communication capability. Furthermore, mobile users are accessing the Internet via different types of fixed or wireless access networks, for example a cellular radio communication network, such as a Universal Mobile Telecommunication System (UMTS) network, a HiperLAN/2 or IEEE 802.11b local area network, a Bluetooth™ local communication system, or fixed accesses such as the Ethernet, and so on.
It is currently possible to support handover accessing of the Internet from one access network to another, for example by using a protocol known as Mobile-IP. Traditional mobility support aims to provide continuous Internet connectivity to mobile hosts, thereby allowing individual mobile users to connect to the Internet whilst being mobile by providing the mobile host with the opportunity to move the location of their Internet access. Recently, there has been a significant amount of interest and research in the Mobile IPv6 specification, as described in the document co-authored by David B. Johnson: IETF Internet-Draft draft-ietf-mobileip-ipv6-18.txt, June 2002.
Within IPv6 networks, host devices and client devices are allocated addresses comprising a hundred and twenty-eight bits to identify the device to other devices within, or external to, the network. The one hundred and twenty-eight bit addresses are known as Internet Protocol version 6 Addresses (IPv6 addresses). In the following, the terms IPv6 addresses and IP addresses are used inter-changeably. IP addresses provide a simple mechanism for identifying the source and destination of messages sent within IP networks.
Traditionally, IP addresses that identify devices within IP networks have been assigned in a static manner during network configuration. Using this type of static assignment, data routers and other network components are pre-configured to use the statically assigned address bindings that correlate devices to their IP addresses.
However, in large or rapidly changing networks, static assignment of IP addresses is often inadequate. As a result, several methods have been developed that allow IP addresses to be automatically assigned. The two widely used methods include:                (i) Automatic distribution by central servers, and        (ii) Address derivation by a close cooperation between hosts and the immediately neighbouring router.        
In another method employed in some IP networks, routers analyse IP data packets received from client devices. Every data packet has a source address and a destination address. The source addresses in these data packets are extracted and used to update routes within the router to deliver data packets to and/or from particular devices. In those latter types of networks routes are updated based on the packets circulating within the network, but addresses are not automatically assigned.
A tunnelled packet is a data packet that encapsulates within it another data packet. Thus, the encapsulating data packet has a pair of source and destination addresses. A further encapsulated packet has additional source and destination addresses, and so on. Such a tunnelling mechanism allows a Home Agent to keep track of the current position of a Mobile Node and forward packets from the home position (designated by an IP address, or Home Address) to the new position (a new IP address, or the Care-of Address). From a routing perspective, tunnelling allows a route of the data packet to be determined, e.g. by de-tunnelling the data packets to determine the source address of each encapsulated packet.
Increasingly, IP addresses within networks are assigned by server systems using the Dynamic Host Configuration Protocol (DHCP) as is defined in Internet RFC 1541, which is incorporated herein by reference. For networks that use the DHCP protocol, one or more DHCP servers are configured to listen for messages requesting IP addresses. If possible, the DHCP server then allocates an IP address to the client system that sent the message. The newly allocated IP address is then included in a message sent by the DHCP server to the client system. The IP address is, in effect, provided to the client system on a time-limited basis, thereby allowing reuse of the same addresses by the same or a different client.
In general, the use of DHCP servers to assign IP addresses to client systems has proven to be particularly advantageous, saving non-expert users from manipulating long strings of digits (IP addresses). Furthermore, it allows an administrator tight control over the management of the address pool and guarantees the uniqueness of each used address. This is especially true in networks that include a large number of client systems.
Referring now to FIG. 1, a known IP routing mechanism is described that employs the IETF Mobile IPv6 protocol in a network. As an example, a network that is frequently found in a campus-type mobility network is shown. The network uses link technologies such as Ethernet and 802.11b.
In this regard, a mobile node 160 is operating in a micro-mobility (local-mobility) computer/communication domain. The micro-mobility computer/communication domain is configured as a tree structure, with a gateway 120 between nodes in the local domain and, say, the Internet 110. For example, let us assume the mobile node is a portable computer that is able to communicate with the Internet 110 by wirelessly coupling to any of a number of access points/access routers 140-150.
The access routers are typically coupled to Dynamic Host Configuration Protocol (DHCP) Relays. The routing functionalities (in software) and the DHCP Relay functionalities (in software) are executed within the same access node. Optionally, the two functionalities can be spread over two different nodes, but with the restrictions that:                (i) The Relay must be placed on the link immediately next to the mobile node in order to receive the broadcasted address autoconfiguration messages sent by the mobile node, and        (ii) The Router functionality must be placed as far as possible towards the edge of the local mobility domain in order to ensure correct propagation of routes.        
The micro-mobility domain includes routers 130, 132, 134 to link the access routers/DCHCP relays 140-150 to the gateway that includes a DHCP server 120. When the mobile node 160 has logged on to access router 140, it is assigned a temporary IP address, which is informed 165 to the MN's Home Agent 105. The MN 160 is able to access applications from application server 115, via a route 170 that encompasses the Internet 110, the gateway/DHCP server 120, and a number of serially-coupled intermediate routers 130 (with only one router shown) and the access router 140.
Notably, when the MN 160 logs on to another access router/DHCP relay 150, a new IP address is allocated to the MN. The new IP address is informed in message 175 to the MN's Home Agent 105 so that communication towards the home position (home address) of the MN can be routed to the new position of the MN 160 (Care-of Address). In this regard, a skilled artisan would appreciate that a network that employs an IETF Mobile IPv6 protocol is not ideally suited for managing a micro-mobility (or local mobility) domain. The unsuitability emanates from a high control overhead resulting from frequent notifications to the Home Agent 105.
Methods that use DHCP and Mobile IP to manage mobility at an IP level are described in the documents by Charles E. Perkins, et al.:                (i) “Using DHCP with Computers that Move”, Proceedings of the Ninth Annual IEEE Workshop on Computer Communications, 1994; and        (ii) “DHCP for Mobile Networking with TCP/IP”, Proceedings of the IEEE Symposium on Computers and Communications, 1995.        
DHCP is used to dynamically obtain a Care-of-Address (CoA) that will subsequently be registered with a Home Agent. In this manner, a Home Agent builds and maintains IP tunnels that deliver packets to mobile nodes through the routers 130, 132, 134.
A significant problem with mobile nodes is the requirement to assign new CoAs as and when the mobile node accesses the network via a different access point. Furthermore, the tunnelling requirement in such IP systems, particularly in a micro-mobility domain, has been appreciated by the inventors of the present invention as a further significant disadvantage.
U.S.005812819A, titled “Remote Access Apparatus and Method which Allow Dynamic Internet Protocol (IP) Address Management”, describes a mechanism to use the same CoA whilst changing points of attachment. The primary focus of U.S.005812819A is to use a unique personal identifier, such that with each re-connection, a user obtains the same CoA. However, although U.S.005812819A describes the maintenance of the same CoA, the mechanism still requires, and therefore suffers from the disadvantages of, inter-domain tunnelling by a Home Agent of Mobile IPv6.
‘Address auto-configuration protocols’ have been identified as an important requirement for IP mobile nodes in the following documents:                (i) Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Internet Draft, draft-ietf-dhc-dhcpv6-19.txt; and        (ii) “DHCP for IPv6” by Charles E. Perkins, et al. Bound, and published at the Third IEEE Symposium on Computer and Communications, 1998.        
The reasons identified for address auto-configuration protocols being an important requirement for IP mobile nodes include:                (a) Due to the wide Internet penetration having led to the Transport Control Protocol (TCP)/IP stack to be deployed in general-purpose computing machines, the user of such a machine rarely has the skill (or the desire) to manually configure its TCP/IP stack.        (b) With the advent of smaller and ubiquitous devices, it is often the case that there is no user to configure the device stacks: they must be configured as Plug-n-Play.        
In IPv6 there exist two address autoconfiguration mechanisms: ‘stateless’ and ‘stateful’. The important difference between these two mechanisms is that stateful autoconfiguration uses a pair of hosts (server and relay) to maintain an address database as well as to relay a node's request and relay replies in the allocation of an address across a network. In stateless autoconfiguration the message exchange for autoconfiguration is limited to one link and there is no state to maintain.
WO9826549, titled “Method for Using DHCP to Override Learned IP Addresses in a Network”, describes a method whereby DHCP messages are scanned for IP assignment events. When an event is triggered, a pre-configured IP route is updated in a central ‘router’ table.
Each route provides a mapping between an IP address and a client system. When the router receives an IP packet, it extracts the destination address of the packet from the packet's header. The router then searches the route table for a route that matches the destination address of the received IP packet. If the router finds a matching route, the router forwards the IP packet to the client system included in the matching route.
Notably, the method is applicable in a dialup environment, where all clients connect to one router and all accessed servers are situated directly connected on the same router. Hence, the applicability of WO9826549 is very limited.
Using the DHCP protocol, client systems request and receive dynamically allocated IP addresses from the DHCP server systems. The router listens for DHCP ACK messages sent by DHCP server systems to the client systems. The DHCP ACK message includes an IP address that has been allocated to a specific client system. When the router detects a DHCP ACK message, the router extracts the IP address allocated for the client system. Using the IP address included in the DHCP ACK message, the router “learns” the IP address of the client system requesting an IP address. The router then adds the route to its route table. The new route is marked to indicate that the DHCP server has assigned it. Thereafter, the router will only relearn this IP address if it is reassigned by the DHCP server system.
In some cases, the learned IP address will conflict with a route originally configured within the router's route table. In these cases, the conflicting route is removed from the route table. In this way, WO9826549 allows routes that reflect dynamically allocated IP addresses to replace already configured routes. The inventors of the present invention have recognised and appreciated the limitations of this method in that it is only able to update routers with new IP routes and is inadequate to handle new IP routes in a network scenario.
Moreover, the method provides for updates within only one “central” router, where all clients and servers are connected and using it as a unique “central” node of communication. It is known that such star networks are not implementable for large systems with hundreds of clients and thousands of servers. The inventors of the present invention have recognised a need to provide for route updates within an entire cloud of routers, where everything is connected in a mesh-like topology, scaling the number of routes to connect any number of clients and servers.
U.S. Pat. No. 6,249,523, titled “Router for which a Logical Network Address which is not Unique to the Gateway Address in Default Routing Table Entries”, presents a method to update ARP cache entries, effectively “routing” in a local broadcast link only, when triggered by DHCP messages.
It is noteworthy that the document titled “Cellular IPv6, Internet Draft Personal Proposal”, draft-shelby-seamoby-cellular-ipv6-00.txt. describes a mechanism to manage IP mobility within a domain by appropriately updating per-host IP routes. Cellular IPv6 is a new protocol, which has been pending standardization for a number of years. Cellular IPv6 is equivalent to other routing protocols such as RIP. One of the reasons that Cellular IP has yet to be accepted for standardization is its use of paging concepts, which are natural in a 3GPP environment. However, such concepts are unfeasible with IP protocols, due to architectural inefficiencies such as network flooding (broadcast) of periodic (time-triggered) data over a large number of networks. Furthermore, the route status in this document is limited to a “personal proposal”. As such, the mechanism is inadequate for standard IP mobility scenarios.
In summary, the inventors of the present invention have recognised that present implementations of IPv6 suffer from the need to regularly signal to remote home agents when a mobile node is mobile, for example, continuous updating of the mobile node's CoA. Furthermore, IPv6 introduces problems in tunnelling requirements, when some configurations may not necessarily need to incur such complex and bandwidth/throughput costly mechanisms. Current attempts at resolving one or more of the above problems have a consequent effect on other IP protocols.
USPTO Backgrounds
USPTO Backgrounds