Enabling services for multiple sessions using a single mobile node

1. Field of the Invention

The present invention relates to Mobile IP network technology. More particularly, the present invention relates to enabling multiple sessions or services for separate devices or applications associated with a single mobile node.

2. Description of the Related Art

Mobile IP is a protocol which allows laptop computers or other mobile computer units (referred to as “Mobile Nodes” herein) to roam between various sub-networks at various locations—while maintaining internet and/or WAN connectivity. Without Mobile IP or related protocol, a Mobile Node would be unable to stay connected while roaming through various sub-networks. This is because the IP address required for any node to communicate over the internet is location specific. Each IP address has a field that specifies the particular sub-network on which the node resides. If a user desires to take a computer which is normally attached to one node and roam with it so that it passes through different sub-networks, it cannot use its home base IP address. As a result, a business person traveling across the country cannot merely roam with his or her computer across geographically disparate network segments or wireless nodes while remaining connected over the internet. This is not an acceptable state-of-affairs in the age of portable computational devices.

To address this problem, the Mobile IP protocol has been developed and implemented. An implementation of Mobile IP is described in RFC 2002 of the Network Working Group, C. Perkins, Ed., October 1996. Mobile IP is also described in the text “Mobile IP Unplugged” by J. Solomon, Prentice Hall. Both of these references are incorporated herein by reference in their entireties and for all purposes.

The Mobile IP process and environment are illustrated in FIG. 1 . As shown there, a Mobile IP environment 2 includes the internet (or a WAN) 4 over which a Mobile Node 6 can communicate remotely via mediation by a Home Agent 8 and a Foreign Agent 10 . Typically, the Home Agent and Foreign Agent are routers or other network connection devices performing appropriate Mobile IP functions as implemented by software, hardware, and/or firmware. A particular Mobile Node (e.g., a laptop computer) plugged into its home network segment connects with the internet through its designated Home Agent. When the Mobile Node roams, it communicates via the internet through an available Foreign Agent. Presumably, there are many Foreign Agents available at geographically disparate locations to allow wide spread internet connection via the Mobile IP protocol. Note that it is also possible for the Mobile Node to register directly with its Home Agent.

As shown in FIG. 1 , Mobile Node 6 normally resides on (or is “based at”) a network segment 12 which allows its network entities to communicate over the internet 4 through Home Agent 8 (an appropriately configured router denoted R 2 ). Note that Home Agent 8 need not directly connect to the internet. For example, as shown in FIG. 1 , it may be connected through another router (a router R 1 in this case). Router R 1 may, in turn, connect one or more other routers (e.g., a router R 3 ) with the internet.

Now, suppose that Mobile Node 6 is removed from its home base network segment 12 and roams to a remote network segment 14 . Network segment 14 may include various other nodes such as a PC 16 . The nodes on network segment 14 communicate with the internet through a router which doubles as Foreign Agent 10 . Mobile Node 6 may identify Foreign Agent 10 through various solicitations and advertisements which form part of the Mobile IP protocol. When Mobile Node 6 engages with network segment 14 , Foreign Agent 10 relays a registration request to Home Agent 8 (as indicated by the dotted line “Registration”). The Home and Foreign Agents may then negotiate the conditions of the Mobile Node's attachment to Foreign Agent 10 . For example, the attachment may be limited to a period of time, such as two hours. When the negotiation is successfully completed, Home Agent 8 updates an internal “mobility binding table” which specifies the care-of address (e.g., a collocated care-of address or the Foreign Agent's IP address) in association with the identity of Mobile Node 6 . Further, the Foreign Agent 10 updates an internal “visitor table” which specifies the Mobile Node address, Home Agent address, etc. In effect, the Mobile Node's home base IP address (associated with segment 12 ) has been shifted to the Foreign Agent's IP address (associated with segment 14 ).

Now, suppose that Mobile Node 6 wishes to send a message to a corresponding node 18 from its new location. An output message from the Mobile Node is then packetized and forwarded through Foreign Agent 10 over the internet 4 and to corresponding node 18 (as indicated by the dotted line “packet from MN”) according to a standard internet protocol. If corresponding node 18 wishes to send a message to Mobile Node—whether in reply to a message from the Mobile Node or for any other reason—it addresses that message to the IP address of Mobile Node 6 on sub-network 12 . The packets of that message are then forwarded over the internet 4 and to router R 1 and ultimately to Home Agent 8 as indicated by the dotted line (“packet to MN( 1 )”). From its mobility binding table, Home Agent 8 recognizes that Mobile Node 6 is no longer attached to network segment 12 . It then encapsulates the packets from corresponding node 18 (which are addressed to Mobile Node 6 on network segment 12 ) according to a Mobile IP protocol and forwards these encapsulated packets to a “care of” address for Mobile Node 6 as shown by the dotted line (“packet to MN( 2 )”). The care-of address may be, for example, the IP address of Foreign Agent 10 . Foreign Agent 10 then strips the encapsulation and forwards the message to Mobile Node 6 on sub-network 14 . The packet forwarding mechanism implemented by the Home and Foreign Agents is often referred to as “tunneling.”

As described above, the mobile node's IP address (i.e., Home Address) is typically used to identify the mobile node. Thus, when messages are sent to a mobile node, they are sent to that mobile node's IP address. However, in order to enhance the interoperability of roaming and tunneling services, it is desirable to have a standardized method for identifying users. Such a standardized method is proposed in RFC 2486 of the Network Working Group, January 1999, which proposes syntax for the Network Access Identifier (NAI), the userID submitted by a client during Point to Point Protocol (PPP) authentication. Thus, when a client is authenticated based upon the NAI, an IP address may be allocated for use by the client.

When a client is static within a single network, an IP address may be assigned in most cases based solely on the NAI. In addition, as described in Internet Draft “http://search.ietf.org/internet-drafts/draft-ietf-mobileipi-mn-nai-07.txt,” submitted by the Mobile IP Working Group, Jan. 12, 2000, it has been proposed that the NAI be used to identify a mobile node in order for an IP address (i.e., Home Address) to be assigned. However, this technique is inappropriate in those instances when the client is a mobile node that wishes to roam among different networks. More particularly, when an IP address is assigned by a network access server (NAS), this IP address is assigned based upon the dial in port from a pool of addresses associated with a particular network and therefore the assigned IP address cannot be used within the additional networks to which the mobile node roams. In addition, since the IP address is mapped to the NAI, a problem occurs when more than one node or application wishes to roam using the same mobile node 6 and therefore the same NAI. In other words, when multiple nodes or applications are authenticated based upon the same NAI, a single IP address will be allocated for two different sessions (e.g., devices or applications). Accordingly, mobility cannot be enabled in two different devices or applications based upon the same NAI.

In view of the above, it would be desirable if a mechanism for enabling services to multiple sessions (e.g., devices or applications) via a single or multiple mobile nodes could be established. Moreover, it would be preferable if the sessions could be authenticated using the NAI associated with the mobile node through which the sessions are enabled.

Methods and apparatus for performing registration on behalf of a session associated with a mobile node are disclosed. A session may be an application (e.g., running on the mobile node) as well as a device that is separate from the mobile node. More particularly, the device need not support Mobile IP. Accordingly, through the present invention, the mobile node may perform a proxy registration on behalf of one or more associated sessions.

In accordance with one aspect of the invention, the mobile node composes a registration request including a NAI identifying a userID (e.g., submitted during PPP authentication) and a sub-NAI that uniquely identifies a session associated with the NAI. For instance, the NAI and sub-NAI may be appended to the registration request in separate extensions to the registration request. The mobile node then sends the registration request to the Home Agent.

In accordance with another aspect of the invention, when the Home Agent authenticates the mobile node based upon information in the registration request, the Home Agent composes and sends a registration reply. In the registration reply, the Home Agent returns an IP address associated with the session. As one example, the IP address may be obtained from the Home Address field of the registration request. As another example, the IP address may be obtained from an entry in a mobility binding table associated with the Home Agent. In addition, the Home Agent may map this IP address to the NAI and sub-NAI in a mobility binding table associated with the Home Agent. Thus, the Home Agent may subsequently use the mobility binding table to route packets addressed to this session via the IP address.

In accordance with yet another aspect of the invention, when the registration reply is received by a Foreign Agent to which the mobile node has roamed, the Foreign Agent may update its visitor table to associate the NAI and sub-NAI with the IP address assigned to that session. In this manner, the Foreign Agent may identify those sessions that are visiting the Foreign Agent.

The present invention enables multiple sessions to be enabled via a single or multiple mobile nodes. This is accomplished through the use of a NAI associated with the mobile node and a sub-NAI that uniquely identifies a session associated with the NAI. Accordingly, multiple Mobile IP sessions may be enabled simultaneously via a single mobile node.

FIG. 1 is a diagram of a Mobile IP network segment and associated environment.

FIG. 2 is a block diagram illustrating a Mobile IP network segment and associated environment in which multiple sessions may be enabled through a single mobile node.

FIG. 3 is a process flow diagram illustrating the steps performed during registration on behalf of a new session in accordance with an embodiment of the invention.

FIG. 4 is a process flow diagram illustrating the steps performed during registration by a mobile node in accordance with an embodiment of the invention.

FIG. 5 is a process flow diagram illustrating the steps performed during registration by a Foreign Agent to process a registration request in accordance with an embodiment of the invention.

FIG. 6 is a process flow diagram illustrating the steps performed during registration by a Home Agent in accordance with an embodiment of the invention.

FIG. 7 is a process flow diagram illustrating the steps performed by the Foreign Agent to process a registration reply in accordance with an embodiment of the invention.

FIG. 8 is a diagram illustrating an exemplary registration request that may be sent by a mobile node in accordance with an embodiment of the invention.

FIG. 9 is a diagram illustrating an exemplary registration reply that may be sent by a Home Agent in accordance with an embodiment of the invention.

FIG. 10 is a diagram illustrating an exemplary mobility binding table that may be used by an active Home Agent in accordance with an embodiment of the invention.

FIG. 11 is a diagram illustrating an exemplary visitor table that may be used by an active Foreign Agent in accordance with an embodiment of the invention.

FIG. 12 is a block diagram of a network device that may be configured to implement aspects of the present invention.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to unnecessarily obscure the present invention.

As described above, it would be desirable to enable multiple sessions via a single mobile node. A simple solution is to provide a unique NAI for each session. Thus, mobility may be enabled in multiple sessions (e.g., devices or applications) if a user simply specifies a unique NAI when registering via a mobile node. Since the Home Agent associated with the mobile node views the two NAIs as unique, the Home Agent provides different IP addresses. However, this solution is undesirable, since it requires a static mapping of the mobile node 6 to the separate devices or applications. As a result, the user's ability to use new devices with the mobile node 6 would be limited.

Through the use of the present invention, mobility may be enabled by a mobile node on behalf of multiple sessions without requiring a static mapping of the mobile node to the separate devices or applications. Registration is performed on behalf of the sessions by the mobile node through the specification of an NAI associated with the mobile node and a sub-NAI (i.e., session identifier) associated with the session. The session identifier need only be unique within the NAI, and therefore is referred to in the following description as a sub-NAI.

As shown in FIG. 2 , it may be desirable to enable two different sessions to be authenticated based upon the same NAI associated with a single mobile node 6 . For instance, the NAI may be an e-mail address or a userId submitted in an application layer authentication. The mobile node 6 may be, for example, a phone that supports Mobile IP. Two different users traveling, for instance, in a car or plane, may each wish to connect a laptop to the phone so that each user may separately communicate remotely over the internet via mediation by a Home Agent and a Foreign Agent. For instance, a first user may connect a first laptop (PC 1 ) 20 to the mobile node 6 while a second user may simultaneously connect a second laptop (PC 2 ) 22 to the same mobile node 6 . A NAI 24 (“Kleung”) associated with the mobile node 6 is submitted in the registration request in order to authenticate the mobile node 6 . However, an IP address returned by the Home Agent 8 based upon this authentication will be identical for both users since the NAI 24 is not unique for each session. As a result, the present invention associates a session identifier (i.e., sub-NAI) with each session (e.g., laptop). As shown, a first sub-NAI 26 , “KleungPC 1 ,” is associated with the first laptop 20 and a second sub-NAI 28 , “KleungPC 2 ,” is associated with the second laptop 22 . Although the sub-NAIs are shown to be strings, the sub-NAI may be implemented in a variety of formats. An IP address may then be allocated by the Home Agent 8 based upon the NAI and associated sub-NAI for the particular session. The IP address may thereafter be used by that session in subsequent communications with a corresponding node. This permits corresponding nodes to continue using the same IP address to communicate with a device or application associated with the mobile node during a given session.

FIG. 3 is a process flow diagram illustrating the steps performed during registration on behalf of a new session in accordance with an embodiment of the invention. As shown at block 302 the mobile node composes and sends a registration request including an NAI and a sub-NAI on behalf of a new session. In addition, the registration request specifies a care-of address of a Foreign Agent to which the session wishes to roam and a Home Agent address associated with the mobile node. The Foreign Agent receives the registration request and forwards the registration request to the Home Agent at block 304 . The Home Agent performs authentication based upon the NAI, composes the registration reply with the IP address assigned to that session and sends the registration reply to the Foreign Agent at block 306 . At block 308 the Foreign Agent receives the registration reply and forwards the registration reply to the mobile node so that it can map the IP address to the session. Accordingly, the mobile node may subsequently use the IP address to identify packets that are sent by that session as well as packets that are addressed to that session.

As shown at block 302 of FIG. 3 , the mobile node is responsible for composing and sending a registration request on behalf of a new session (e.g., device or application). FIG. 4 is a process flow diagram illustrating the steps performed during registration by a mobile node on behalf of a session in accordance with an embodiment of the invention. When the mobile node detects the start of a new session (e.g., application or device) at block 402 , the mobile node composes a registration request at block 404 . As described in RFC 2002, the registration request must identify the Home Agent associated with the mobile node. In addition, in order to enable the Home Agent to uniquely assign an IP address to the session, a NAI and sub-NAI are specified. More particularly, in accordance with one embodiment, the NAI and sub-NAI are each provided in a separate extension to the registration request. Thus, at block 406 , the mobile node appends separate NAI and sub-NAI extensions to the registration request. The NAI extension includes a NAI identifying a userID submitted (e.g., during PPP authentication) while the sub-NAI uniquely identifies a session associated with the NAI. The registration request is then sent at block 408 .

As described above with reference to block 304 of FIG. 3 , the Foreign Agent is responsible for receiving and forwarding the registration request. FIG. 5 is a process flow diagram illustrating the steps performed during registration by a Foreign Agent to process a registration request in accordance with an embodiment of the invention. As shown at block 502 , the Foreign Agent receives the registration request including the NAI and sub-NAI extensions and forwards the registration request to the Home Agent identified by the Home Agent address at block 504 .

Once the Home Agent receives the registration request including the NAI and the sub-NAI identifying a session associated with the NAI, it composes a registration reply as described above with reference to block 306 of FIG. 3 . FIG. 6 is a process flow diagram illustrating the steps performed during registration by a Home Agent in accordance with an embodiment of the invention. First, the Home Agent authenticates the mobile node. For instance, authentication may be performed using the NAI obtained from the registration request at block 602 .

Upon completion of authentication of the mobile node performing the proxy registration on behalf of the associated session, the Home Agent composes and sends a registration reply. In order to provide an IP address for the session, the Home Agent determines whether a binding already exists between the NAI, sub-NAI and an IP address in a mobility binding table associated with the Home Agent at block 604 . At block 606 , if there is a binding in the mobility binding table for the NAI, sub-NAI and an IP address, this IP address is obtained from the mobility binding table at block 608 . Otherwise, the Home Agent decides whether it needs to assign an IP address to the mobile node for this particular session at block 610 . For instance, an indicator may be set in the registration request or a specific indicator may be placed in the Home Address field of the registration request. If the Home Agent determines at block 612 that a new IP address is needed, a new IP address is obtained at block 614 . Otherwise, the IP address from the Home Address field of the registration request is obtained at block 616 . The Home Agent then updates the mobility binding table as necessary with a binding between the NAI, the sub-NAI and the IP address at block 618 .

After the IP address for the mobile node is obtained, the registration reply is composed at block 620 . More particularly, as described above, the Home Address field of the registration reply includes the IP address. In addition, the NAI and the sub-NAI are included in the registration reply. For instance, as described above with reference to the registration request, the NAI and sub-NAI may be provided in separate extensions to the registration reply. The Home Agent then sends the registration reply at block 622 .

When the Foreign Agent receives the registration reply, it updates its tables and forwards the reply to the mobile node performing the proxy registration. FIG. 7 is a process flow diagram illustrating the steps performed by the Foreign Agent to process a registration reply in accordance with an embodiment of the invention. As shown at block 702 , the Foreign Agent receives the registration reply including the NAI and sub-NAI information. The Foreign Agent then updates its visitor table as necessary with a mapping of the NAI, the sub-NAI and the IP address associated with the mobile node at block 704 . The Foreign Agent then sends the registration reply to the mobile node at block 706 . The mobile node then maps the IP address for the session to the session information at block 708 . More particularly, the mobile node maps the IP address to the NAI and sub-NAI obtained from the registration reply. As described above, the NAI and the sub-NAI may be obtained from one or more extensions to the registration reply. Once the mobile node has mapped this session information to the IP address, the mobile node may subsequently forward packets to the appropriate session (e.g., application or device) using this information. Accordingly, the mobile node may have multiple associated IP addresses.

As described above with reference to FIG. 4 , the mobile node composes a registration request on behalf of an application or device. FIG. 8 is a diagram illustrating an exemplary registration request that may be sent by a mobile node in accordance with an embodiment of the invention. As shown, the registration request 802 includes a NAI extension 804 including a NAI and a sub-NAI extension 806 including a sub-NAI. The sub-NAI may be provided in the registration request 802 by the mobile node. Alternatively, the sub-NAI may be provided in the registration request 802 by the Foreign Agent during registration.

Similarly, when authentication is completed, a registration reply is sent by the Home Agent to the mobile node. FIG. 9 is a diagram illustrating an exemplary registration reply that may be sent by a Home Agent in accordance with an embodiment of the invention. As shown, the registration reply 902 includes a NAI extension 904 including a NAI and a sub-NAI extension 906 including a sub-NAI. Although the NAI and sub-NAI are provided in separate extensions to the registration request and registration reply, this information may be provided in an alternate manner. For instance, this information may be provided in the registration request and/or reply packets in unused fields or, alternatively, may be provided in a single extension.

During the registration process, the Home Agent may need to update its mobility binding table as shown at block 618 of FIG. 6 . When the Home Agent updates an associated mobility binding table, the IP address associated with that session is mapped to session information for that session. FIG. 10 is a diagram illustrating an exemplary mobility binding table that may be used by an active Home Agent in accordance with an embodiment of the invention. The mobility binding table includes a NAI 1002 , a sub-NAI 1004 , and an IP address 1006 associated with that session. From this information, the Home Agent may determine during the registration process whether a binding exists between a NAI, a sub-NAI and an IP address. Moreover, the entry for this session is associated with a care-of address 1008 (e.g., foreign agent address) and a tunnel interface 1010 . In addition, the mobility binding table may include other information such as the lifetime of the particular session. In this manner, the Home Agent may identify the session that has registered with the Home Agent via the mobile node. Moreover, the mobility binding table may include care-of address associations for additional nodes that do not implement the Mobile IP protocol (and other mobile nodes implementing the Mobile IP protocol) based with the same Home Agent. Such additional nodes may be linked to the Foreign Agent or any other Foreign Agent that has registered a Mobile IP connection.

As described above with reference to block 704 of FIG. 7 , the Foreign Agent may update its visitor table to identify those sessions that have roamed to the Foreign Agent. FIG. 11 is a diagram illustrating an exemplary visitor table that may be used by an active Foreign Agent in accordance with an embodiment of the invention. As shown, the NAI 1102 and sub-NAI 1104 are mapped to the IP address 1106 that identifies this particular session. From this information, the Foreign Agent may monitor and limit the number of registration requests a particular user sends out. In addition, the visitor table includes an IP address of the Home Agent 1108 and a corresponding interface 1110 . More particularly, the session is associated with the interface and its Home Agent through specifying a tunnel to the Home Agent. Accordingly, through the visitor table, the Foreign Agent may route data packets to the session via the assigned IP address.

Once the registration phase has been completed, the mobile node may use the assigned IP address on behalf of a session in its communication with corresponding nodes. These corresponding nodes may then send packets to this assigned IP address. The Home Agent then forwards these packets to the appropriate Foreign Agent using its mobility binding table. Since the Foreign Agent has access to the IP address in its visitor table, these packets may be forwarded to the mobile node associated with the assigned IP address. The IP address may be de-allocated at a later time to permit the IP address to be reassigned to another mobile node. Thus, as the mobile node roams from foreign agent to foreign agent, the mobile node may keep the IP address for a particular session from the first registration until it is de-allocated. This permits corresponding nodes to continue using the same IP address to communicate with the session (e.g., application or device) via the mobile node. Thus, through proxy registration by a mobile node on behalf of an associated session (e.g., device or application), multiple users may roam the Internet via the mobile node. Thus, multiple devices may be simultaneously connected to the mobile node in order to enable mobility in these devices. Accordingly, through such “proxy” registration, nodes that do not have Mobile IP software, hardware and/or firmware may be provided Mobile IP functionality.

The apparatus (Home Agent, Foreign Agent, and/or node) of this invention may be specially constructed for the required purposes, or may be a general purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. The processes presented herein are not inherently related to any particular router or other apparatus. In a preferred embodiment, any of the Home and Foreign Agents of this invention may be specially configured routers such as specially configured router models 2500, 2600, 3600, 4000, 4500, 4700, 7200, and 7500 available from Cisco Systems, Inc. of San Jose, Calif. A general structure for some of these machines will appear from the description given below.

Generally, the registration technique of the present invention may be implemented on software and/or hardware. For example, it can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card. In a specific embodiment of this invention, the technique of the present invention is implemented in software such as an operating system or in an application running on an operating system.

A software or software/hardware hybrid registration system of this invention is preferably implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. Such programmable machine may be a network device designed to handle network traffic. Such network devices typically have multiple network interfaces including frame relay and ISDN interfaces, for example. Specific examples of such network devices include routers and switches. For example, the registration systems of this invention may be specially configured routers such as specially configured router models 1600, 2500, 2600, 3600, 4500, 4700, 7200, 7500, and 12000 available from Cisco Systems, Inc. of San Jose, Calif. A general architecture for some of these machines will appear from the description given below. In an alternative embodiment, the registration system may be implemented on a general-purpose network host machine such as a personal computer or workstation. Further, the invention may be at least partially implemented on a card (e.g., an interface card) for a network device or a general-purpose computing device.

Referring now FIG. 12 , a router 1310 suitable for implementing the present invention includes a master central processing unit (CPU) 1362 , interfaces 1368 , and a bus 1315 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 1362 is responsible for such router tasks as routing table computations and network management. It may also be responsible for updating mobility binding and visitor tables, etc. It preferably accomplishes all these functions under the control of software including an operating system (e.g., the Internetwork Operating System (IOS®) of Cisco Systems, Inc.) and any appropriate applications software. CPU 1362 may include one or more processors 1363 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 1363 is specially designed hardware for controlling the operations of router 1310 . In a specific embodiment, a memory 1361 (such as non-volatile RAM and/or ROM) also forms part of CPU 1362 . However, there are many different ways in which memory could be coupled to the system.

The interfaces 1368 are typically provided as interface cards (sometimes referred to as “line cards”). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the router 1310 . Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 1362 to efficiently perform routing computations, network diagnostics, security functions, etc.

Although the system shown in FIG. 12 is one specific router of the present invention, it is by no means the only router architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the router.

Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory 1361 ) configured to store program instructions for the general-purpose network operations and mechanisms for registration and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The memory or memories may also be configured to store tables such as mobility binding and visitor tables, etc.

Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). The invention may also be embodied in a carrier wave travelling over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.

Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. For example, although the NAI has been described as a userID submitted during PPP authentication, the NAI may be any identifier that is used to identify a mobile node. More particularly, the NAI may be used to identify a mobile node that needs a home address. In addition, although the specification has described routers, other entities used to tunnel packets to mobile nodes on remote network segments can be used as well. For example, bridges or other less intelligent packet switches may also employ the standby protocol of this invention. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.