Fumio Teraoka. April 15, 1992

Transcription

1 Host Migration in Virtual Internet Protocol Fumio Teraoka SCSL-TR April 15, 1992 Sony Computer Science Laboratory Inc Higashi-gotanda, Shinagawa-ku, Tokyo, 141 JAPAN Copyright c 1992 Sony Computer Science Laboratory Inc

2 In Proceedings of the 1st International Networking Conference, June, 1992

3 Host Migration in Virtual Internet Protocol Fumio Teraoka Sony Computer Science Laboratory Inc Higashigotanda, Shinagawa-ku, Tokyo 141, Japan Abstract In the near future, a user will carry his portable computer and access the wide area network regardless of location In such an environment, host migration transparency is an essential feature of the wide area network Virtual Internet Protocol (VIP) is a network layer protocol providing host migration transparency, which is derived from Internet Protocol (IP) Currently, VIP is running on Unix based workstations This paper describes the procedures of VIP focusing on host connection/disconnection to/from a subnetwork We implemented two daemon processes and two new commands to support the migration procedures In VIP, applications can specify a migrating host by its VIP address regardless of location Examples show that a TCP connection is preserved while a host is disconnected from the network Measured overhead of connection/disconnection procedures is also shown 1 Introduction The conventional protocol suites, such as OSI [5] and TCP/IP, do not consider host mobility As an exception, XNS [11] can keep track of migrating hosts by using a name server mechanism However, current name servers and directory services in a wide area network environment, such as network directory [1] and domain name system [6], are not suitable to handle dynamic data such as location of migrating hosts There are some proposed protocols to support host mobility In [4], host migration is supported by IPwithin-IP datagram This method uses a radio network interface to support a set of mobile hosts within a campus Each mobile host (MH) has a unique IP address which never changes even if the host moves Each mobile support station (MSS) has a service area of a radio subnetwork and keeps track of MHs All MHs must have the same (sub)network number as a part of IP address for packet routing from a 'regular' host to an MH When an MSS relays a packet to an MH which does not exist in the service area of the MSS, the MSS must search for the location of the MH by querying other MSSs Thus, this method seems to have a problem with scalability We claimed that the network layer must provide host migration transparency and proposed the concept of virtual network [10] A virtual network is a logical network Each host in the wide area network is logically always connected to its home network even if it physically migrates so that it has a migration independent network address Such a migration independent network address is called a virtual network address or a VN-address Since the transport and higher layer protocols specify the target host by a VN-address, higher protocols are not aware of host migration The conventional network address of a host indicates its physical location or the subnetwork in which the host exists We call the conventional network address a physical network address or a PN-address Thus, a host has two network addresses in the virtual network environment To deliver a packet to a host, the PN-address of the target host must be resolved from its VN-address To incorporate such function into the network layer, we divided the conventional network layer into two sublayers: the virtual network sublayer or the VN-sublayer and the physical network sublayer or the PN-sublayer The VN-sublayer converts the VN-address specied by the transport layer into the corresponding PN-address by the propagating cache method [10] In the propagating cache method, each host and gateway has a cache for address conversion This cache is called the Address Mapping Table or the AMT Cache entries propagate across the wide area network as communication progresses Virtual Internet Protocol (VIP) is derived from Internet Protocol (IP) by applying the concept of virtual network and the propagating cache method [8] In [8], measured communication performance in stable state is also shown This paper focuses on the transit state, ie connection/disconnection of a host to/from a subnetwork When a host is connected to a subnetwork, it must be 1

4 assigned a temporary IP address and send a control packet When a host is about to disconnect from a subnetwork, it must release the temporary IP address VIP does not include such IP address management functions To support such functions, we introduced two daemon processes: migd and vipd One migd is running per subnetwork and one vipd is running on each migrating host They communicate with each other to execute the host migration procedures such as IP address allocation/release Section 2 presents the overview of Virtual Internet Protocol In tion 3, we dene the procedures required on host connection and disconnection, which are not included in VIP Section 4 gives our implementation of the migration procedures Examples are also shown in this tion Section 5 presents measured overhead of VIP Section 6 concludes this paper 2 Virtual Internet Protocol This tion gives an overview of Virtual Internet Protocol (VIP) VIP is derived from Internet Protocol (IP) by applying the concept of virtual network and the propagating cache method According to the protocol hierarchy described in the previous tion, the conventional IP layer is divided into two sublayers: the VIP sublayer and the IP sublayer 21 IP address and VIP address Since the IP address represents the location of a host, it is thought of as a PN-address We introduced the VIP address as a VN-address The VIP address of a host never changes A host is assigned a VIP address in the VIP sublayer and an IP address in the IP sublayer Both addresses have the same format If a host exists in its home network, both addresses have the same value There are two implementation approaches for VIP: the sublayer approach and the IP option approach According to the protocol hierarchy, the former is preferable However, the latter is preferable in terms of backward compatibility [9] The VIP header in the IP option approach is shown in Figure 1 In the gure, the upper half is the conventional IP header The lower half is the VIP header as an IP option The VIP header consists of eight elds: option type (V IP OptT ype ) and option length (V IP OptLen ): these two elds are dened in IP [7] type (V IP type ): there are six types: { V ipdata: data { V ipconn: connection notication { V ipconnack: acknowledgment of V ipconn { V ipdisc: disconnection notication ver ttl ihl opt type id tos proto source IP address destination IP address opt len source VIP address destination VIP address source address timestamp destination address timestamp f total length fragment oset header checksum type hold Figure 1: VIP header format { V ipdelamt: AMT entry deletion { V iperrobs: obsolete AMT entry error hold time (V IP hold ): initial value of the AMT idle eld (see below) of the AMT entry for the source host of this packet source and destination VIP addresses (V IP SrcAddr and V IP DstAddr ) source and destination address timestamps (V IP SrcT S and V IP DstT S ): the version number of the source IP/VIP address pair and the destination IP/VIP address pair, respectively An AMT entry for VIP consists of four elds, each of which is 4 bytes long: VIP address (AMT V IP ): acts as key of this entry IP address (AMT IP ): the requested value address timestamp (AMT AddrT S ): version number of the IP/VIP address pair of this entry idle timer (AMT idle ): used for aging of this entry 22 Data Communication Protocol On a source host, TCP/UDP issues a transmission request to the VIP sublayer with the VIP address of the destination host The VIP sublayer searches for the AMT entry for the destination host to resolve the destination IP address If the entry is found, the VIP sublayer issues a transmission request to the IP sublayer with the destination IP address Otherwise, the VIP sublayer assumes that the destination host exists in its home network, ie destination IP address is equal 2

5 to its VIP address, and then the VIP sublayer issues a transmission request to the IP sublayer Upon receiving a VIP packet on an intermediate gateway, it creates or updates the AMT entry for the source host of the received packet and searches for the AMT entry of the destination host If the entry is found and it holds newer data than the packet has, the destination IP address eld in the IP header is modied On the destination host, the AMT entry for the source host is created or updated as same as on a gateway Finally, the received data is passed to TCP/UDP Thus, as communication progresses, the AMT entry of a migrating host propagates across the wide area network Address conversion for the rst packet sent to a migrating host might be done by an intermediate gateway on the path to the home network of the migrating host In the worst case, address conversion is done by the home gateway of the migrating host However, once a host receives a VIP packet from a migrating host, it can directly send packets to the migrating host since it makes the AMT entry of the migrating host 23 Host Migration Protocol When a migrating host is connected to a subnetwork, it is assigned a temporary IP address Next, it sends a VipConn packet to its home network and waits for a VipConnAck packet The VipConn packet is relayed by gateways Since the VipConn packet includes the VIP and IP addresses of the source host, intermediate gateways can learn the relation of these two addresses and create or update the AMT entry for the source host The home gateway, which is the gateway in the home network of the migrating host, receives the Vip- Conn packet, creates the AMT entry for the migrating host, and returns the VipConnAck packet The home gateway also broadcasts the VipConn packet within the home network of the migrating host if the home network is a broadcast type network such as Ethernet In addition, the home gateway creates an entry in the ARP table for the migrating host to answer the ARP request for that host Note that on the home gateway, AMT entries for hosts for which it is the home gateway are never timed out When a migrating host is about to disconnect from a subnetwork, it sends a VipDisc packet to its home gateway When the home gateway receives the VipDisc packet, it broadcasts the VipDelAmt packet to all subnetworks to which it is connected Gateways in the subnetwork receive the VipDelAmt packet If a gateway has the AMT entry for the migrating host, it deletes the entry and also broadcasts the packet to any other connected subnetworks If a gateway does not have an AMT entry for the migrating host, the gateway does nothing Thus, most AMT entries of the migrating host are deleted when the host is about to disconnect from a subnetwork 3 Procedures for Host Migration There are two types of host migration: o-line and online In o-line migration, a host is disconnected from the network during moving whereas in on-line migration, a host can access the network during moving In the conventional wired network, only o-line migration is possible If wireless network such as cellular telephony and radio LAN systems becomes widely available, on-line migration becomes feasible In this paper, we focus on o-line migration 31 Connection Procedure The connection procedure is executed when a host is connected to a subnetwork It is also executed in booting process In this paper, we assume that a host has 1 Activate the Ethernet interface 2 Get the network number of the current subnetwork to know whether the current subnetwork is its own home network an Ethernet interface When a host is connected to a subnetwork, it has no IP addresses, routing information, nor idea whether the subnetwork is its home network In the connection procedure, a host must get such information The connection procedure is as follows: 3 If the current subnetwork is its own home network, execute the 'regular' booting procedure Otherwise, execute the procedure below 4 Notify the operating system of its VIP address 5 Get a temporary IP address and assign it to the Ethernet interface 6 Get the IP address of the default gateway in the current subnetwork and add it to its routing table 7 Execute the connection protocol described in Section 23 After this procedure is done, the migrating host has a temporary IP address The relation between its VIP address and the temporary IP address is registered in the home gateway of the migrating host as well as intermediate gateways on the transmission path of the VipConn packet The cache of this relation will propagate across the wide area network as communication with this host progresses 32 Disconnection Procedure The disconnection procedure is executed when a host is about to disconnect from a subnetwork The disconnection procedure is as follows: 3

6 1 If the current subnetwork is its own home network, nothing to do Otherwise, execute the procedure below 2 Execute the disconnection protocol described in Section 23 3 Release the temporary IP address 4 Deactivate the Ethernet interface After this procedure is done, the home gateway of the migrating host has deleted the entry for the host Since the home gateway broadcasts the VipDelAmt packet, most AMT entries for the host in the wide area network are deleted 33 Temporary IP Address As described above, when a migrating host is connected to a subnetwork other than its home network, the host must be assigned a temporary IP address There are three temporary IP address allocation strategies: 1 dynamic: any migrating hosts can be connected to the subnetwork A temporary IP address is allocated to a migrating host from the temporary IP address pool in turn The temporary IP addresses allocated to migrating hosts must be recalled when hosts disconnect from the subnetwork 2 dynamic & registered: only registered migrating hosts can be connected to the subnetwork A temporary IP address is allocated to a registered migrating host from the temporary IP address pool in turn The temporary IP addresses allocated to migrating hosts must be recalled when hosts disconnect from the subnetwork Although the number of migrating hosts which can be connected to the subnetwork simultaneously is limited to the number of temporary IP addresses, the number of registered hosts is unlimited 3 static: only registered migrating hosts can be connected to the subnetwork The relation between the VIP address and the IP address is registered in advance The number of registered migrating hosts is limited to the number of temporary IP addresses The recall of allocated temporary IP addresses is not necessary Although the third strategy might be easiest to implement among them, it has a problem with scalability The number of migrating hosts which can be connected to a subnetwork is limited to a small number From view point of network management, the ond strategy is preferable to the rst because the ond strategy can avoid connection of unknown hosts Due to ease of implementation, we chose the rst strategy in the current implementation 4 Implementation 41 Daemons To support the host migration procedures, we introduced two daemons: migd (migration support daemon) and vipd (vip daemon) Migd is running per subnetwork whereas vipd is running on each migrating host They communicate with each other when a migrating host is connected/disconnected to/from a subnetwork We reserve two IP addresses, INADDR MIGD and IN- ADDR VIPD, for the communication between migd and vipd There are some protocols for hosts which do not have an IP address initially, such as RARP [3] and BOOTP [2] RARP is a protocol specic to Ethernet whereas BOOTP runs on UDP Although the current implementation of VIP assumes Ethernet as the data link media, we chose BOOTP as the protocol between migd and vipd because BOOTP is independent of data link media Our protocol exploits the vender dened area of the BOOTP packet format When a migrating host is connected to a subnetwork, it has no IP addresses At rst, it assigns its network interface the IP address INADDR VIPD and sends a request packet to migd with the destination address INADDR MIGD by using Ethernet broadcast Since a request packet includes the VIP address of the migrating host as the source address, migd can uniquely identify the source host of a request packet The host on which migd is running receives this request packet and returns a reply packet with destination address INADDR VIPD by using Ethernet broadcast Since a reply packet also includes the VIP address of the migrating host as the destination address, the migrating host can receive correct packets The reason why migd returns a reply packet by using Ethernet broadcast is that there might be two or more migrating hosts waiting for a reply simultaneously If the normal method is used, ie the host on which migd is running sends an ARP request for INADDR VIPD, a reply packet might be delivered to an incorrect host Migd is started by the command line below: migd netif [conf-le] (eg migd en0 /migdconf) where netif is the network interface name to be used and conf-le is a conguration le specifying available IP addresses and the IP address of the default gateway When migd terminates due to shutdown, etc, it saves the mapping between IP addresses and VIP addresses to the conguration le in order to restore the mapping after restart Figure 2 shows an example of the conguration le In this example, ten available IP addresses are registered and none of them are currently allocated Vipd is started by the command line below: 4

7 # default gateway gateway # # ip vip Figure 2: an example of migd conguration le vipd [-b] netif my-vipaddr home-gw (eg vipd -b en ) where netif is the network interface to be used, myvipaddr is the VIP address assigned to the host, and home-gw is the (V)IP address of the home gateway of the host Vipd starts the connection procedure if the switch -b] is specied Vipd also starts the connection procedure when receiving a signal SIGUSR1 and starts the disconnection procedure when receiving a signal SIGUSR2 or SIGTERM 42 Command Modication In the BSD kernel, each network interface such as Ethernet is managed by the structure in ifaddr An entry was added to the structure in ifaddr in order to hold the VIP address of the host To set and get the VIP address of a host, we modied the command ifcong Upon showing the interface status, the VIP address is preceded by a new keyword vnet See Section 45 To set the network interface the VIP address, the same keyword is also used, eg ifcong en0 vnet wwxxyyzz We implemented two new commands: plugin and unplug The command plugin has vipd start the connection procedure by sending a signal SIGUSR1 to vipd The command unplug has vipd start the disconnection procedure by sending a signal SIGUSR2 to vipd Both the commands have no arguments We also implemented two commands, vipconn and vipdisc, for debugging The commands vipconn and vipdisc only send a VipConn and VipDisc packet to the specied home gateway, respectively The command syntax of these commands is as follows: vipconn netif home-gw vipdisc netif home-gw where netif and home-gw have the same meaning as those in the command line of vipd 43 Migd Enhancement There are three points to be improved in the current migd implementation The rst point is the lack of a procedure to recall unused IP addresses In the current IP address allocation strategy, migd must recall an allocated IP address when a migrating host is disconnected from a subnetwork Although the command unplug triggers the disconnection procedure, some migrating hosts might not execute this command In the current migd implementation, if a migrating host is disconnected without the command unplug, the IP address allocated to the host cannot be recalled Thus, migd must examine whether the host to which a temporary IP address is allocated exists in the subnetwork by methods such as polling The ond point is reliability If migd crashes, migrating hosts cannot get a temporary IP address To avoid this, we plan to introduce master migd and slave migd In each subnetwork, one master migd and one or more slave migds are running All migds receive a request packet destined to INADDR MIGD, however, only master migd replies it Master migd and slave migd(s) periodically communicate with each other to examine whether master migd is available If master migd crashes, one of slave migds becomes temporary master migd When master migd comes back, temporary master migd returns to slave state The third point is to support various types of links In the current implementation, we assume Ethernet as the data link media Migd and vipd should support various types of links such as point-to-point link 44 Packet Flow Figure 3-(a) shows packet ow when a host is connected to a subnetwork other than its home network First, vipd on a migrating host sends a request packet Get- NetNum to migd in order to know whether the current subnetwork is its home network Migd running on a host in the subnetwork receives the packet and returns the network number and netmask to the migrating host The migrating host knows that the current subnetwork is not its home network and then sends a request packet GetIP and GetDefGw in order to get a temporary IP address and the IP address of the default gateway in the subnetwork Migd assigns the migrating host a temporary IP address and noties it of the IP address of the default gateway Finally, the migrating host sends a VipConn packet to its home gateway and receives a VipConnAck packet Figure 3-(b) shows packet ow when a host is connected to its home network A migrating host knows that the current subnetwork is its home network by the query GetNetNum 5

8 If necessary, the migrating host gets the IP address of the default gateway in the subnetwork Figure 4 shows packet ow when a host is disconnected from a subnetwork At rst, a migrating host sends a VipDisc packet to its home gateway Upon receiving this packet, the home gateway broadcasts the VipDelAmt packet to all connected subnetwork in order to delete the AMT entry for that host Next, the migrating host release the temporary IP address migrating host VipDisc FreeIP home migd gateway VipDelAmt migrating host migd home gateway ok GetNetNum net number & netmask GetIP & GetDefGw IP addr & Gw IP addr in foreign subnetwork Figure 4: packet ow on host disconnection line vnet is added to the normal output This output means that this host is assigned a temporary IP address whereas its VIP address, ie , is unchanged VipConn VipConnAck crux% plugin crux% ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet netmask ffffff00 broadcast crux% (a) in foreign subnetwork migrating host migd GetNetNum net num & netmask Figure 5: ifcong output in home network crux% plugin crux% ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet netmask ffffff00 broadcast vnet crux% GetDefGw Figure 6: ifcong output in a foreign network Gw IP addr (b) in home subnetwork Figure 3: packet ow on host connection 45 Examples Figure 5 shows the output of the command ifcong after a host is connected to its home network This output is the normal output of ifcong The IP address of this host is This output implies that the VIP address of this host is the same as its IP address Figure 6 shows the output of ifcong when a host is connected to other than its home network A Figure 7 shows the output of the command telnet In this example, a host named aquila, whose IP and VIP addresses are , executes telnet to a migrating host named crux, whose VIP address is When telnet starts, it resolves the address of crux by a query to the name server The name server returns the VIP address of crux, ie Telnet then establishes a TCP connection to that address The rst ifcong output on crux indicates that crux is currently connected to a network whose network number is Crux then moves to its home network so that the ond ifcong output does not include the line vnet wwxxyyzz Note that the telnet connection is preserved during crux moves if the time in which crux is disconnected from the network is not so long The third ifcong output indicates that crux moves to a network 6

9 aquila% ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet netmask ffffff00 broadcast aquila% telnet crux Trying Connected to cruxcslsonycojp Escape character is '^]' NEWS-OS Release 41C (cruxcslsonycojp) login: tera crux% ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet netmask ffffff00 broadcast vnet crux% crux% ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet netmask ffffff00 broadcast crux% crux% ifconfig en0 en0: flags=63<up,broadcast,notrailers,running> inet netmask ffffff00 broadcast vnet crux% crux% logout Connection closed by foreign host aquila% Figure 7: telnet output whose network number is Performance Currently, VIP is running on SONY NEWS workstations based on 43BSD UNIX We implemented VIP by modifying the operating system kernel A special timer board with a 1 granularity allowed us to evaluate VIP 51 Data Packet Handling Table 1 presents the time required for transmission, relay, and reception for a data packet in stable state in both IP and VIP+IP [8] Stable state means that the source host has the AMT entry for the destination host, the gateway has the AMT entries for both the source and destination host, and the destination host has the AMT entry for the source host Therefore, address conversion for the destination host is done at the source host before sending According to the result, if the processing power of each host or gateway is equal to that of SONY NEWS workstations, host-to-host overhead of VIP in comparison to IP can be formulated by a function of hop count (N hop ) as follows: host-to-host overhead = 100N hop () VIP overhead will be 07 m if N hop is 5 and 12 m if N hop is 10 Since IP transmission in the Internet takes time in 100 m order, host-to-host VIP overhead is negligible Tables 2 to 4 show the transmission, relay, and reception overhead in detail In transmission, the function ip insertoptions is called to insert the VIP header to the IP header because VIP is implemented by exploiting an IP option eld The function requires 28 % of the transmission overhead Due to the same reason, in relay and reception, the function ip dooptions is called and requires 27 % and 32 % of the overhead, respectively, although ip dooptions does nothing for VIP 52 Control Packet Handling When a host is connected to a subnetwork, it sends a VipConn packet to its home gateway This packet is relayed to the home gateway and it returns a VipConnAck packet to the source host Thus, the overhead of host connection at an intermediate gateway is the relay time of the VipConn and VipConnAck packets At a home gateway, it is the handling time of a Vip- Conn packet When a host is about to disconnect from a subnetwork, it sends a VipDisc packet to its home gateway This packet is also relayed to the home gateway and it broadcasts a VipDelAmt packet to all subnetworks to which it it connected Thus, the overhead of host disconnection at an intermediate gateway is the relay time of the VipDisc packet and handling time of the VipDelAmt packet At the home gateway, it is the handling time of a VipDisc packet The overhead of VipDelAmt handling also incurs at a gateway if it has the AMT entry of the disconnecting host even if it is not on the VipDisc transmission path Tables 5 and 6 show the time required for transmission of the VipConn and VipDisc packets at a migrating host These results are larger than that of VIP data because they include the processing time in the network interface layer In both cases, although the function vip output and ip insertoptions are not called, the function ip output consumes approximately 100 more than transmission time for an IP data packet This overhead is derived from route nding In case of IP data packet transmission, TCP/UDP usually species the output network interface In case of transmission of the VIP control packets, however, the IP layer must search for the output network interface by looking up the routing table In addition, VipConn transmission calls the function m copy to save the packet for retransmission Handling time of the VipConn and VipDisc packets on a home gateway is shown in Tables 7 and 8 These results are much larger than others because these results include packet transmission time Upon receiving 7

10 Table 1: data packet handling time IP VIP overhead transmission (154 %) relay (33 %) reception (127 %) Table 2: VIP overhead on transmission transmission overhead: 120 vip output: 77 vip setsrc ip insertoptions check header conv others Table 3: VIP overhead on relay relay overhead: 100 vip forward: 66 ip dooptions others vip modamt vip mapdst others Table 4: VIP overhead on reception reception overhead: 84 vip input: 57 ip dooptions vip modamt check others a VipConn packet, the home gateway broadcasts it in the home network and returns a VipConnAck packet to the source host of the VipConn packet Upon receiving a VipDisc packet, the home gateway broadcasts a VipDelAmt packet to all subnetworks to which it is connected In VipConn handling, the home gateway creates an AMT entry for the source host in the function vip modamt This handling time requires 265 and seems too large We plan to improve the performance of this function Required time for VIP control packet relay is shown in Table 9 Relay of the VipConnAck and VipDisc packets requires less time than normal VIP data packet because these packets do not cause AMT entry manipulation In case of VipDelAmt packet relay, the AMT entry for a disconnecting host is deleted and the packet is relayed to all subnetworks except the incoming one 6 Conclusion In the near future, host migration transparency will be an essential feature of the wide area network We proposed the concept of virtual network and the propagating cache method to achieve this VIP is a virtual network protocol derived from IP In a VIP environment, the VIP sublayer hides host migration entirely so that it is not necessary to modify TCP/UDP and application programs including name servers, that is, name servers return the VIP address, not IP address, of a requested host name, TCP/UDP issues a transmission request to the VIP sublayer with the VIP address of the destination host, the VIP sublayer converts the VIP address to the corresponding IP address, and then the IP sublayer delivers a packet to the destination host In this paper, we described the procedures for host migration in detail We implemented two daemons, migd and vipd, and two new commands, plugin and unplug, to execute the connection/disconnection procedures The command ifcong was modied to set/get the VIP address of a host Examples showed that an application program can specify a migrating hosts by its name regardless of its location and that a TCP connection is preserved while the host is moving We also presented the measurement results of required time for normal data transfer and control packet transfer In stable state, VIP can achieve host migration transparency in the Internet with negligible overhead in comparison to IP We also plan to implement VIP on the MuseOS [12], an object-oriented distributed operating system being developed at SonyCSL 8

11 Table 5: VipConn transmission time on a migrating host VipConn transmission: 574 vip txvipconn: 151 ip output ether, etc copyin check header m copy Table 6: VipDisc transmission time on a migrating host VipDisc transmission: 502 vip txvipdisc: 109 ip output ether, etc copyin check header Table 7: VipConn handling time on a home gateway VipConn: 1756 ipintr vip input: 1658 vip modamt check vip setarptab vip bcastconn vip txconnack others vip bcastconn: 695 header ip output ether, etc vip txconnack: 473 header ip output ether, etc Table 8: VipDisc handling time on a home gateway VipDisc: 1625 ipintr vip input: 1527 delete AMT entry delete ARP tab entry vip bcastvipdel others vip bcastdel: 1437 (2 ethers) header 1st loop 2nd loop others one loop: 676 header ip output ether, etc Table 9: control packet handling time on an intermediate gateway VipConn VipConnAck VipDisc VipDelAmt VipDelAmt: 855 ipintr delete AMT entry vip sendvipdel others

12 Acknowledgment I give my thanks to Dr Mario Tokoro of Sony CSL/Keio University, Dr Hideyuki Tokuda of Carnegie Mellon University/Keio University, Dr Jun Murai of Keio University, Ms Kim Clay of University of California, San Diego, the members of the WIDE project, and the members of Sony Computer Science Laboratory Inc Discussions with them helped me re- ne the concept of virtual network and its adaptation to IP I also give my thanks to Mr Hiroshi Tezuka and the members of Super Micro Group of SONY Corporation, who made the customized timer board which allowed me to evaluate VIP [12] Yasuhiko Yokote, Fumio Teraoka, Atsushi Mitsuzawa, Nobuhisa Fujinami, and Mario Tokoro The Muse Object Architecture: A New Operating System Structuring Concept Operating Systems Review, 25(2), February 1991 References [1] CCITT The Directory { Overview of Concepts, Models and Services November 1988 X500 [2] Bill Croft and John Gilmore Bootstrap Protocol (BOOTP) September 1985 RFC951 [3] R Finlayson, T Mann, J C Mogul, and M Theimer Reverse Address Resolution Protocol June 1984 RFC903 [4] John Ioannidis, Dan Duchamp, and Gerald Q Maguire Jr IP-based Protocols for Mobile Internetworking In Proceedings of ACM SIG- COMM 91, September 1991 [5] ISO Information processing systems { Open Systems Interconnection { Basic Reference Model 1984 ISO7498 [6] P V Mockapetris Domain Names { concepts and facilities November 1987 RFC1034 [7] J B Postel Internet Protocol September 1981 RFC791 [8] Fumio Teraoka, Kim Clay, and Mario Tokoro Design, Implementation, and Evaluation of Virtual Internet Protocol In Proceedings of the 12th International Conference on Distributed Computing Systems, June 1992 [9] Fumio Teraoka and Mario Tokoro Host Migration Transparency in IP Networks: The VIP Approach Technical Report, SCSL-TM , Sony Computer Science Laboratory Inc, December 1991 [10] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro A Network Architecture Providing Host Migration Transparency In Proceedings of ACM SIGCOMM 91, September 1991 [11] Xerox Internet Transport Protocols XEROX CORPORATION, December 1981 XSIS