servers of mobile services. The speci cations of the 34 portable PCs are shown in Table 1. BSD machines indicate IBM ThinkPad 560(Pentium 133MHz, 24MB).
A Network Architecture for Continuous Mobility Keisuke Uehara1 , Takamichi Tateoka2 , Yasuhito Watanabe1 , Hideki Sunahara3 Osamu Nakamura1 and Jun Murai1 1
Keio University, 5322 Endo, Fujisawa-shi, Kanagawa 252-0816, Japan 2 The University of Electro-Communications, 1-5-1, Chofugaoka, Chofu, Tokyo 182, Japan 3 Nara Institute of Science and Technology, 8916-5 Takayama, Ikoma, Nara 630-01, Japan Abstract. A system architecture for continuous mobility of Internetconnected computers is designed and proposed. The architecture considers network transparency, geographical location transparency, and performance transparency, with strong support for mapping between an identi er space of the Internet and geographical location information. The architecture is de ned by 1) identi er space support functions, 2) continuous Internet connectivity functions, and 3) performance transparency functions. Two experimental systems are implemented based on the architecture and are tested. The systems achieve continuous mobility in practical environments for automobiles connecting to the Internet, and in classrooms with about 40 roaming students.
1
Introduction
Many issues arise ranging from the hardware level to the application level to construct an actual mobile computing environment. For example, at the hardware level, a computer must be small and portable. At the data link level, wireless communication technologies for both the local area and the wide area must be established. At the network level, seamless connectivity from/to mobile nodes must be provided. At the application level, new applications speci c to a mobile environment must be developed. As of today, most of the problems at the hardware level have been solved. Computers are small and light enough for users to carry them. The PC card technology allows dynamic recon guration of network interfaces of a computer, e.g., from a 10BASE-T interface to a wireless LAN interface. Some problems for mobility support have been solved and some remain unsolved in the Internet environment. At the IP level, seamless communication from/to mobile nodes can be achieved by employing Mobile IP[1][2] or VIP[3], i.e., location transparency has been solved. At the TCP level, however, communication throughput decreases in some conditions[4], i.e., performance transparency is not achieved. Although some middle-ware systems such as the Coda le system[5] take disconnected operation into account, there are only a few applications designed speci cally for the mobile computing environment. Domain
names are usually used to specify the target computer in the Internet. However, another naming architecture should also be considered for the mobile computing environment, where it is very convenient for a user to specify target computer by its location instead of its domain name, e.g., the nearest print server. Security must be taken into account at all levels. Security is generally categorized into authentication, integration, and secrecy. In the current Internet environment, organizations are usually connected to the Internet via rewall machines to protect the intranet from intruders. However, it is very inconvenient for a mobile user if it is impossible to communicate with computers via rewalls. Secured rewall traversal must be provided to mobile users. The NECM (Network Environment for Continuous Mobility) project started in April 1996 to build an actual mobile computing environment. It is a joint project between Keio University, Toshiba Corp., Sun Microsystems, and Stanford University. The NECM project has developed many new technologies such as GLI (Geographical Location Information System)[6], PFS (Personal File System)[7], and LWP (Light Weight Protocol)[8]. We also implemented some standardized protocols such as Dynamic Host Con guration Protocol (DHCP)[9][10] and Dynamic Domain Name System (DynDNS)[11][12][13][14] from scratch. In November 1997, we tested our testbed for a mobile computing environment at Shonan Fujisawa Campus of Keio University.
2
Existing Technologies
Figure 1 depicts existing technologies for a mobile computing environment. At the data link level, wireless communication technologies such as Personal Digital Cellular (PDC)4 /Personal Digital Cellular Packet (PDC-P) and IEEE802.11 are available. When a mobile node moves to another subnet, it must be reassigned an IP address. DHCP provides mechanisms to assign network parameters such as an IP address. To achieve seamless communication from/to a mobile node, Mobile IP was developed. Dynamic DNS is useful to support node mobility if Mobile IP is not available in the IP level, i.e., the new IP address of a mobile node is immediately re ected to the domain name system. At the middle-ware level, the Coda le system allows disconnected access to a network le system. This section gives overviews of these existing technologies and clari es the remaining unsolved problems.
2.1 DHCP DHCP is a client-server type protocol that can be used to dynamically assign network parameters to clients. DHCP supports over 60 parameters, including IP address, netmask, default route, etc. A mobile node can obtain an IP address when it moves to another subnet, and then it can communicate with other nodes. However, the mobile node cannot be identi ed by an immutable identi er if only DHCP is used. 4
The digital cellular system in Japan
Applications File System
Name Space DNS
NFS bind Comm. API TCP
UDP
IP Dyn. Host Conf. PPP
Wireless WAN PDC/PDC-P PHS
PSTN
Fig. 1.
Ethernet
Wireless LAN IEEE 802.11
Geograph. Info. GPS PHS
Block diagram of existing technologies
2.2 Mobile IP Mobile IP allows seamless communication with mobile nodes. A mobile node can move to subnets served by FAs (Foreign Agent). A mobile node can be identi ed by its home address regardless of its location although its care-of address changes when it moves. There are two ways to assign a care-of address: a FA noti es the mobile node of its care-of address or the mobile node obtains its care-of address by using DHCP. The latter case is called co-located care-of address. In both cases, the binding between the home address and the care-of address is registered with the HA (Home Agent) of the mobile node. The HA announces the routing information for the mobile nodes it manages. When a node sends an IP packet to a mobile node, this packet rst reaches the HA of the mobile node in accordance with the routing information announced by the HA. The HA encapsulates the received IP packet within another IP header and forwards it to the FA that currently serves the mobile node. The FA decapsulates the received packet and forwards the original IP packet to the mobile node. In case of co-located care-of address, the HA directly forwards the encapsulated packet to the mobile node. Thus, every packet sent to a mobile node travels on a redundant route. A packet from the mobile node to its correspondent node travels on the optimal route.
2.3 Dynamic DNS Dynamic DNS[14] provides a method to dynamically update DNS entries. It is an extension of DNS. The message includes existing entries and update information. When a server receives an update request message, it authenticates the requesting host and updates the entry. Dynamic DNS has a mechanism to keep consistency of the database. If a slave server receives the message, it forwards the message to the master server because only the master server is allowed to update entries.
2.4 Coda File System The Coda le system, which was developed by CMU as the successor to the Andrew File System, is a le system that supports disconnected operations. It has two operation modes: connected and disconnected. In connected mode, the Coda le system stores les as caches when les are accessed. Also a user can request to store les explicitly. This behavior is almost the same as the Andrew File System. When a host is disconnected, the system provides accessibility to les by using cached data. However, the Coda le system does not take care of characteristics of network connectivity5 . Heavy trac is charged to communication links even if a host is connected by PDC. Furthermore, modi cations to operating systems are required to install the Coda le system.
2.5 Unsolved Problems If a mobile node has a single network interface such as Ethernet, DHCP and Mobile IP can provide seamless mobility. Assume that a mobile node uses a wireless LAN interface in a room while it uses a PDC interface outdoors. In this case, automatic interface switching must be provided when the mobile node moves across the boundary. In addition, packet routes to mobile nodes are always redundant in Mobile IP. Route optimization must be incorporated with mobility support communication protocols such as Mobile IP. In the mobile computing environment, users want to know the physical location of the target node. Users can know the IP address (or the care-of address if Mobile IP is used) but they cannot know the physical location because there are no mechanisms for mapping IP addresses and geographical location information.
3
New Technologies
To solve the problems described in Sect. 2.5, the NECM project developed some new technologies. Figure 2 depicts the block diagram of the modules to build a continuous mobility environment. In the gure, bold italic fonts indicate new technologies the NECM project developed. 5
LITTLE WORK Project at Michigan University introduced the adopt mode for low bandwidth connection to the Coda File System[15].
Applications File System Net. File System PFS CODA
Name Space DNS newbie bind
NFS
Geograph. Info. GLI System
Comm. API Transport LWP
TCP
UDP
IP Mobility Mobile IP VIP IP
PPP
Dyn. Net. Conf. DNCP
Dyn. Host Conf. DHCP
IF Switching IF-SW
Wireless WAN PDC/PDC-P PHS
PSTN
Fig. 2.
Ethernet
Wireless LAN IEEE 802.11
Geograp. Info. GPS PHS
Block diagram of the NECM system
3.1 Interface Switching Assume that more than one data link are available at the same time in a mobile computing environment. These data links might have di erent characteristics. A wireless LAN supports high speed communication in a limited area. PDC and PDC-P provide wide area communication but is expensive. Personal Handyphone System (PHS) can be used in a wide area but cannot communicate with moving nodes. The technologies to switch currently available data links with user preferences are required in the wireless communication environment. We designed the interface switching technologies to support switching available network interfaces. A user preference description le is stored in a node. According to user preference and availability of the interfaces, the system automatically switches the network interfaces. For example, a car in a garage communicates by a wireless LAN. When the car moves to out of the wireless LAN area, PDC or PDC-P will be automatically started. When the car stops in a crossing, it dumps data with PHS link. After returning to the garage, the interface is switched to the wireless LAN link and PDC or PDC-P link is shutdown. Currently, an implementation on BSD/OS 3.0 is available.
3.2 Virtual IP Virtual IP (VIP) is another mobile capable Internet Protocol. VIP supports the basic idea of dynamic binding of a a host identi er and a host locator. VIP capable routers (VIP Routers) have an address mapping table (AMT). AMT is used to bind a host identi er (VIP address) and a host locator (IP address). The home network of a Mobile Node (MN) has a Home Router (HR) which maintains an AMT entry of the MN. When the MN moves to a foreign network, the MN requests a temporary IP address as a locator by DHCP. The MN announces \the VIP address to IP address" binding to the HR. The HR and intermediate VIP routers between the MN and the HR store the \VIP address/IP address" pair in their AMT as a cache entry. A packet from a Correspondent Node (CN) to the MN is forwarded to the home network of the MN. The HR or a VIP router on the path between the CN and the HR captures this packet and forwards it to the MN location (the destination address in the IP header is rewritten from the VIP address of the MN to the current IP address of the MN). In VIP, the route between a CN and a MN is automatically optimized. When an announce of a VIP address/IP address pair does not reach the HR because of network partitioning, VIP routers provide functions to reroute a packet to the MN. Figure 3 shows the locus of packets to the MN. In this gure, the destination host is a MN. Its HR is called the primary resolver. Currently, VIP is running on BSD/OS 2.1, BSD/OS 3.0, and NEWS-OS 4.2.
primary resolver
secondary resolver secondary resolver (temporary proxy) resolver holding obsolete entry source host destination host
(a)
(b)
(c)
Fig. 3.
(d)
VIP overview
3.3 Light Weight Protocol Communication using PDC is unstable in a mobile environment. PDC provides very strong recovery functions. Since PDC recovery looks like congestion of the link, TCP performs retransmission. Thus, performance is degraded further.
In order to utilize the PDC link eciently, the Light Weight Protocol (LWP) is required instead of TCP. TCP communication with PDC link are divide into two parts. The communication between the Internet node and an access point of PDC link uses TCP while communication between an access point of PDC and the node connected by PDC link is controlled by LWP on the PDC. At the access point, packets are forwarded from TCP to LWP and vise versa. Figure 4 shows the LWP architecture. Currently, implementation on the BSD/OS 2.1 and 3.0 is available. End Host1 TCP IP
TCP
App.
TCP
IP LWP
Link
End Host2
GW2
GW1
App.
Link
TCP IP
LWP IP Link
Link
Wired Network Wireless Network Wired Network Fig. 4.
Light Weight Protocol architecture
3.4 Personal File System In the UNIX operating system, a le system is the base of applications. To provide a comfortable computing environment to users, a le system that supports disconnected operatable is required. With the Personal File System (PFS), users can access les whenever the machine is connected or disconnected. Figure 5 shows the system structure of PFS.
MS
SHARED
CUP with VIP
CS
CACHE
application
DISK
DISK NFS
OS
OS
FILE SERVER Fig. 5.
CLIENT (MOBILE) HOST
System structure of PFS
Files are prefetched to the local disk. To consider the status of connection
to the Internet (connected, disconnected, and connected with low bandwidth), PFS provides the following four modes. 1. NFS Compatible (Synchronous) Mode This mode is used on a high bandwidth connection (such as Ethernet). In this mode, operations to the le system are performed in synchronously. This mode is semantically compatible with NFS operations. 2. Asynchronous Mode This mode is used on a mid-bandwidth connection (such as a 9.6Kbps PPP link). In this mode, operations to the local cache data and operations between a client and a le server are performed asynchronously. 3. Fetch Only Mode This mode is used on a low bandwidth connection. In this mode, only le fetching is allowed. 4. Disconnected Mode This mode is for disconnected operation. Operations to the le system are performed only on local cache data. After reconnecting to the Internet, a house keeping operation will start to keep the consistency of the le system. Con icts of updated les are automatically detected by the system. Users solve con icts manually. Thus, in the current implementation, PFS is suitable for accessing ones home directory and similar les. Currently, PFS is running on the BSD/OS 3.0, FreeBSD 2.2.5, Read Hat Linux, SunOS 4.1, Solaris 2.6, and NEWS-OS 4.2.
3.5 Geographical Location Information To manage bindings between geographical location information and network location information, we designed the Geographical Location Information (GLI) system. The GLI system collects and manages the geographical location information of each node in the Internet. Mobile nodes continuously announce current geographical location information to a server. By accessing the server, users can extract the current geographical location information of nodes. The current GLI system provides the following two types of queries.
{ Where are you?
Query the current location of the speci ed node. { Who is there? Query the current members within the speci ed location.
The current system is designed as a centralized database structure. Thus, it does not scale. We started rebuilding the GLI system with a distributed database structure.
4
Testing and Results
To discuss feasibility of the proposed architecture, we provide two types of test scenarios. The rst scenario is the classroom model. This scenario is designed to measure performance of Mobile IP and VIP. Another scenario is the Internet car model. This scenario is designed to con rm the process of the system in a poor communication environment.
4.1 Classroom In the classroom scenario, Mobile-IP, VIP, PFS and GLI were tested. 34 Portable PCs that supported these software modules were used. These PCs moved between two classrooms. The status logs were saved on the each portable PC and servers of mobile services. The speci cations of the 34 portable PCs are shown in Table 1. BSD machines indicate IBM ThinkPad 560(Pentium 133MHz, 24MB). Linux machines indicate DEC HiNote Ultra II(Pentium 120MHz, 24MB).
Table 1. Portable PCs for the classroom scenario OS Mobility Support GLI PFS IF ping Num. of PCs BSD/OS Toshiba Mobile-IP Yes Yes Wireless Yes 1 BSD/OS Toshiba Mobile-IP No Yes Wireless Yes 9 BSD/OS VIP Yes Yes Wireless Yes 10 Linux Stanford Mobile-IP No Yes 10BaseT No 8 Linux Sun Mobile-IP No Yes 10BaseT No 6
H1
H2
H3
R1 R2 R3
MHs
Fig. 6.
R4
MHs
Classroom testbed
Figure 6 shows the network con guration of the classroom scenario including mobile service servers. H1(Cyrix6x86+PR200, 64MB) performs the following functions: the Home Agent of Mobile-IP, the Home Router of VIP, the Master Server of PFS. H2(Pentium 100MHz, 32MB) is the target machine of the ping from the portable PCs. H3(Pentium ODP 83MHz, 24MB) is a GLI server. The link between R1 and R2 is an ADSL link: from R1 to R2 is 7Mbps and from R2 to R1 is 1Mbps. All other links are Ethernet connections. R3 and R4 are PCs running BSD/OS. In this scenario, at rst, all PCs are gathered in the ROOM 2. Then, the PCs were moved to ROOM 1. The Number of the machines that were moved to ROOM1 simultaneously, was 4, 8, 12, 20, and 34. On this situation, we measured the load on each network segment, the load of the each mobile service servers (including Home Agent, Foreign Agents, and Home Router), and mode transition of the PFS client.
Applications File System Net. File System PFS CODA
Name Space DNS newbie bind
NFS
Geograph. Info. GLI System
Comm. API Transport LWP
TCP
UDP
IP Mobility Mobile IP VIP IP
PPP
Dyn. Net. Conf. DNCP
Dyn. Host Conf. DHCP
IF Switching IF-SW
Wireless WAN PDC/PDC-P PHS
PSTN
Fig. 7.
Ethernet
Wireless LAN IEEE 802.11
Geograph. Info. GPS PHS
Test items in classroom environment
The objective of this test is to measure the performance of Mobile IP and co-operability of the various software modules. Figure 7 shows the software used in the NECM system. PFS, GLI system, Mobile IP, VIP, and DHCP were used in this environment.
4.2 Internet Car In the Internet car scenario, we provide ve cars. Each car has a di erent con guration as shown in the Table 2. The ve Internet cars are equipped with a portable PC (Toshiba Portage 300CT, MMX Pentium 133MHz, 64MB), data collection box6 , GPS, wireless LAN (except car 5), and cellular phone.
Table 2.
car # car1 car2 car3 car4 car5
Internet car con guration
Mobility Support IF SW GLI PFS Toshiba Mobile IP Automatic Yes Yes Stanford Mobile IP Manual Yes Yes Sun Mobile IP Manual Yes Yes VIP Manual Yes Yes LWP NA Yes Yes
Figure 8 shows the network con guration of the Internet car scenario. In this gure, H1 performs following functions: the Home Agent of Mobile-IP, the Home Router of VIP, and the Master Server of PFS. H2 is the target machine of the le transfer from the car PCs. H2 also runs as the server for nttcp. H3 is a GLI server. B1 is a base station (wireless - wired bridge) of the wireless LAN. We assume this network simulated a garage for the cars (small circle in the gure). The large circle shows the area of the cellular phone network. In this gure, car 1 and car 2 are connected with cellular phones. Car 3 is connected with wireless LAN.
H1
H2
R1
H3 B1
R2 Car2
Internet
Fig. 8.
Car3
Car1
Internet car testbed
With this network, we accumulated the status logs in the following scenario. 6
This box was developed to obtain raw data of the cars and GPS. Data include latitude, longitude, altitude, pulse count of car speed, switch status of wiper and lights.
1. 2. 3. 4. 5. 6. 7. 8. 9.
In the garage, start up the PCs on the car (connected with wireless LAN). Start the programs for GLI and PFS measurement. Start measurement with nttcp. Moving to outside of the garage (automatic/hand-operated switching from wireless LAN to PPP with cellular phone). Continue the measurement with nttcp. Start le transfer from H1 to PC in the car. Return to the garage (reconnect to the wireless LAN). End of le transfer. Continue the measurement with nttcp.
Applications File System Net. File System PFS CODA
Name Space DNS newbie bind
NFS
Geograph. Info. GLI System
Comm. API Transport LWP
TCP
UDP
IP Mobility Mobile IP VIP IP
PPP
Dyn. Net. Conf. DNCP
Dyn. Host Conf. DHCP
IF Switching IF-SW
Wireless WAN PDC/PDC-P PHS
PSTN
Fig. 9.
Ethernet
Wireless LAN IEEE 802.11
Geograph. Info. GPS PHS
Test items in Internet car environment
4.3 Results We analyzed the status log data of tests described in the previous section. In this section, we discuss the result of analysis of status log data.
Performance of Mobile IP. Before discussion on the performance, we have
to mention the behavior of Mobile IP in the test environment. In the Internet car test, all implementations of Mobile IP were interoperable. The di erences between each implementation were not detected in this test. When the interfaces were switched, Mobile IP software detected it and re-registered the care-of address to its HA automatically. In the classroom testing environment, the software automatically detected Agent Advertisement and switched registered FAs. Network location transparency is established by Mobile IP and VIP. Tests of classrooms and Internet car show ecient result in load of HA and throughput of network. On HA, load becomes larger according to the number of MN. Figure 10 shows the load incurred on HA. The values are integration of load averages. The loads were measured, when 8 MNs, 16 MNs and 24 MNs were receiving data from a CH. When MNs sent data, the loads of the HA were also measured. However the load on HA did not change.
Num. of PCs 8
6.67
12
8.67
24
229 1
2
4
Fig. 10.
10
20
40
100 200
Load
Load on Home Agent
Figure 11 indicates the relationship between the number of MNs and throughput of networks with Mobile IP. It was measured by MNs with a wired link. According to this result, throughput of data ow from CH to MN is slower than reverse ow. The result is due to the performance of the HA.
State transition of PFS. For disconnected operations, mode transition of PFS was observed. Current version of PFS includes a function that measures link performance in order to check the status of the link from outside the device. In our tests, once PFS moved to an unstable state, PFS did not return to stable state. This means that it is dicult to determine the link status from outside the device. Automatic con guration. Figure 12 shows the connection status of car 1.
This car made a one day round trip from Fujisawa to Tsukuba. The horizontal axis shows the time from start of the round trip. At 0 second, the car is in the garage. In the garage, the car was connected to the Internet by wireless LAN.
MN-CN CN-MN
1.4 1.2
MN-CN
Mbit/s
1 0.8 0.6 0.4
CN-MN
0.2 0 0
5
10
15
20
25
30
35
num. of hosts
Fig. 11.
Mobile IP throughput with wired link
After leaving the garage, the communication link of the car was changed to cellular phone link. In the trip, connection of cellular phone was intercepted by tunnels, but the system automatically reconnects to the Internet. The behavior of the connection is also shown in 5000 seconds units in Fig. 12 . In the gure, disconnection from 8,000 second to 12,000 second is caused by trouble of cellular phone connection. Disconnection from 13,000 second to 26,000 second shows parking at destination. Disconnection from 28,000 second to 33,000 second is caused by trouble of software.
0
5000
10000
15000
20000
25000
30000
35000
time
Fig. 12.
Connection condition of the car
Geographical Location Information. In the two tests, the geographical location information system was used. MNs in the classroom environment and Internet car environment send GLI update packets to the GLI server every second. The GLI server got the packet and updated the database regardless of the lower layer status such as using an unstable data link status.
5
Consideration
Each implementation of Mobile IP (RFC2002) were interoperable. The implementation of HA could support about 35 MNs. However, the performance of
encapsulation decreased as the number of MNs increased. If more than 40 MNs need to be supported, two or more HA are required. Furthermore, when a MN moved, the connectivity of the MN was recovered immediately. However, VIP needed more time to recover. This di erence is due to the FA advertisement. When a mobile node runs in co-located care-of address mode, the time needed to recover was the same as VIP. In addition, the co-operation with DHCP and interface status are strongly required. Interface switching is very dicult to implement. Problems arise because some of the software modules are implemented as kernel modules or as application software. Also, although some state transitions of interfaces can be detected in hardware, the device drivers ignore such state transitions. The GLI system is currently implemented as a directory service. It works well when there are a small number of users and agents. We are designing the next version of the GLI system. It has a distributed server architecture. Also the application program interface (API) of the GLI system needs to be redesigned. The current API is not familiar with end users. LWP and PFS can provide performance improvements in an unstable environment. The performance improvements are described in [7] for PFS and [8] for LWP. LWP improves performance by as much as 17 % for an unstable data communication link. The software structure of this project is designed from network and user side views. Although we were able to run the system as a whole, it was very dicult to implement. Current operating systems have no structure to implement these technologies. To support mobility, the network part of operating systems must be reconstructed.
6
Summary
The NECM project developed a system to provide continuous mobility on the Internet by designing an overall architecture for the purpose, and, by designing and implementing component technologies. The designed architecture provides an explicit use of the geographical location so that a user and applications can map a location in the real world to a logical network location of the mapped object. Also, the system achieves the performance transparency on the mobile node on the Internet by introducing the rapid interface switching mechanism and by LWP, the lightweight protocol system. A seamless computing environment is achieved by introducing a transparent mobile le system called the Personal File System. The basic mobility support functions such as Virtual Internet Protocol, DHCP, Mobile IP and Coda were implemented and tested for evaluation purpose to achieve the integrated system. In November 1997, integrated tests were executed in Shonan Fujisawa Campus of Keio University to evaluate our approach. Through these implementations and tests, we obtained feasibility of the NECM system. However, we found that our evaluation was insucient due to lack of measured data. We plan to improve our software and test it again to obtain sucient data.
Acknowledgments We would like to thank the members of following groups for co-operation and valuable discussions: WIDE Project and NECM(Network Environment for Continuous Mobility) Project, Sun Microsystems Inc. Technology Development Group, Stanford University Operating Systems and Networking Group, Toshiba Corp., Sony Computer Science Laboratory Inc., NTT Mobile Communications Network Inc., Honda R&D CO., LTD., Isuzu Advanced Engineering Center, LTD., Nippon Telegraph and Telephone Corp. Wireless Lab., NTT Central Personal Communications Network Inc., Soum Corp., and United Motors. Fumio Teraoka and Atsushi Shionozaki provided insightful comments on this paper. This work was partly funded by MITI(Ministry of International Trade and Industry) through \Advanced Software Enrichment Project" of IPA(Informationtechnology Promotion Agency, Japan)
References 1. J.D.Solomon: MOBILE IP The Internet Unplugged, Prentice-Hall Inc, (1998) 2. C. Perkins: IP Mobility Support, RFC2002, (1996) 3. F.Teraoka, K.Uehara, H.Sunahara, J.Murai: VIP: A Protocol Providing Host Mobility, Communications of the ACM, Vol.37, No.8 (1994) pp.67{pp.75 4. R.Caceres,L.Iftode: Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments, IEEE Journal on Selected Areas in Communications, Vol.13, No.5 (1995). 5. J.J.Kister,M.Satyanarayanan: Disconnected Operation in the Coda File System, Proceedings of the 13th Symposium on Operating Systems Principles (1991). 6. Y.Watanabe, A.Shionozaki, F.Teraoka, J.Murai: The Design and Implementation of the Geographical Location Information System, Proceedings of INET'96 (1996) 7. T.Tateoka, K.Uehara, H.Sunahara, F.Teraoka: PFS: A Dynamically Adaptive File System for Networking Environments, Proceedings of the Internet Conference '96 (1996) pp.81-pp.88 (in Japanese) 8. K.Uehara, A.Nishimura, J.Murai: LWPA: Internet architecture for Wide area wireless communication media, Proceedings of Internet Conference 97 (1997) (in Japanese) 9. A.Tominaga,O.Nakamura,F.Teraoka,J.Murai: Problems and Solutions of Dynamic Host Con guration Protocols(DHCP), Proceedings of INET'95 (1995) 10. R.Droms: Dynamic Host Con guration Protocol. RFC2131, (1997). 11. Y.Doi,M.Minami,J.Murai: Implementation of Name Service for New Environment, Proceedings of Distributed System Management Workshop of IPSJ (Information Processing Society of Japan) (1997), pp.85-pp.90 (in Japanese) 12. P.V.Mockapetris, Domain names - concepts and facilities, RFC1034,(1987) 13. P.V.Mockapetris, Domain names - implementation and speci cation, RFC1035, (1987) 14. P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound: Dynamic Updates in the Domain Name System (DNS UPDATE), RFC2136, (1997) 15. L.Huston,P.Honeyman, Disconnected Operation for AFS, Proceedings of USENIX Mobile and Location-Independent Computing Symposium (1993) pp.1{pp.10. This article was processed using the LATEX macro package with LLNCS style
