home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ien / ien-135 < prev    next >
Text File  |  1988-12-02  |  16KB  |  348 lines
  1.  
  2.  
  3. IEN 135                                                      C. Sunshine
  4.                                                                J. Postel
  5.                                                                  USC-ISI
  6.                                                               March 1980
  7.  
  8.         ADDRESSING MOBILE HOSTS IN THE ARPA INTERNET ENVIRONMENT
  9.  
  10. INTRODUCTION
  11.  
  12. The packet radio network system has been designed from the start with
  13. the idea that hosts could be mobile within a packet radio network.  This
  14. is accomplished by allowing a dynamic binding of host names to the
  15. packet radios that are supporting them, and a dynamic construction of
  16. routes to packet radios as the topology of the network changes.  Hosts
  17. in other types of networks may also be mobile to the extent supported by
  18. those local nets, since the local net portion of an internet address is
  19. left to each local net to interpret as it wishes.  (Hosts on the
  20. original ARPANET are not movable in the sense we mean here because the
  21. net interprets the local net address as a physical IMP interface.)
  22.  
  23. We would also like to allow hosts to move between networks in the
  24. internet system without perturbing protocols above the internet layer.
  25. The particular application we have in mind is a flying packet radio
  26. moving among different packet radio nets, but other types of mobile
  27. hosts may be imagined.
  28.  
  29. With the current understanding of internet addressing, allowing hosts to
  30. move between nets appears to be a more difficult problem than allowing
  31. mobile hosts within one net.  In particular, the network portion of an
  32. internet address is interpreted as specifying the "real" network in
  33. which the host must be found.  Hence a host moving to a new network
  34. would have to take on a new internet address, causing problems for
  35. higher level protocols (e.g. TCP) that use the internet address for
  36. identifying what conversation or connection a message belongs to.
  37.  
  38. To solve this problem, we may try to change the higher level protocols   |
  39. (for example by introducing some "reconnection" or multi-addressing      |
  40. functions), or we may try to change the use of the network identifier at |
  41. the internet level.  This note presents one useful looking possibility   |
  42. in the second area.  The problem of supporting mobile hosts is also      |
  43. related to the problems of multi-homed hosts and network partitioning    |
  44. which we shall return to at the end of this note.                        |
  45.  
  46. PROPOSED SOLUTION
  47.  
  48. Our solution is based on 1) extending the interpretation of network
  49. addresses to include "virtual" nets, and 2) use of source routing.
  50.  
  51. We propose to reserve a set of network identifiers in the internet       |
  52. address space for "virtual" networks which do not correspond to any      |
  53. physical network, but rather to a "community of interest" in which       |
  54.  
  55.  
  56.  
  57. Sunshine & Postel                                               [Page 1]
  58.  
  59.  
  60.  
  61. IEN 135                                                       March 1980
  62. Addressing Mobile Hosts                                                 
  63.  
  64.  
  65.  
  66. "local" names can be uniquely assigned.  In particular, there would be   |
  67. one network identifier for airborne packet radios (e.g. ABPR).  The      |
  68. local portion of the internet address for each airborne packet radio     |
  69. would be a unique (for airborne packet radios) 24-bit number.            |
  70.  
  71. Rather than interpreting the network address in the usual fashion for    |
  72. internet routing, delivery of messages to airborne hosts would require   |
  73. the use of a two-part source route in the following way.  The first part |
  74. would be a normal internet address of a "forwarder," hopefully within    |
  75. the net that the airborne host is currently attached to.  When the       |
  76. message reached this forwarder, it would see the airborne virtual net    |
  77. address in the final part of the source route.  This would cause it to   |
  78. look up in a dynamically maintained table of attached mobile hosts what  |
  79. the proper local address and/or route was to the specified mobile host,  |
  80. and to forward the message accordingly.  Gateways would NOT include      |
  81. virtual nets in the normal internet routing tables, or be able to route  |
  82. packets to such nets directly (unless they were also forwarders).        |
  83.  
  84. The first feature to note about this scheme is that the ultimate
  85. destination address is a new virtual type internet address that remains
  86. unchanged no matter what net the host is attached to.  This allows
  87. higher level protocols to remain unchanged in their mapping of addresses
  88. to connections.
  89.  
  90. The second feature to note is that this freedom for higher level
  91. protocols has its price at the internet level.  We now require 1) the
  92. use of source routing, 2) the maintenance of local address mappings by
  93. forwarders, and 3) the determination of an appropriate forwarder for a
  94. given mobile host.  The second item is exactly the sort of work
  95. currently done by the station in a packet radio net, and we expect this
  96. could be extended to deal with internet format addresses rather easily.
  97. If not the station itself, then the gateway to a packet radio net might
  98. perform this function.
  99.  
  100. The third item seems to require some form of dynamic global data base
  101. that maintains the location of mobile hosts.  When queried with a mobile
  102. host name, it returns the internet address of an appropriate forwarder
  103. to use in constructing a source route to the mobile host.  Of course
  104. this information must be updated as hosts move.  This database may be
  105. centralized, or include several backup servers, or even be distributed
  106. (e.g. among the gateways and/or forwarders which comprise a single
  107. virtual server much like the PSATs in the WBC net).
  108.  
  109. When a host enters a new net (or comes up), it must notify the forwarder |
  110. in that net of its existence (PRs now make a similar notification when   |
  111. the come up in a PR net).  Either the forwarder or the host must also    |
  112.  
  113.  
  114.  
  115. Sunshine & Postel                                               [Page 2]
  116.  
  117.  
  118.  
  119. IEN 135                                                       March 1980
  120. Addressing Mobile Hosts                                                 
  121.  
  122.  
  123.  
  124. notify the global database.  For greater efficiency, the source of any   |
  125. existing connections and the forwarder in the old net could also be      |
  126. notified.  Without these extra notifications, the old forwarder could    |
  127. only notify the source that the host was no longer accessible through    |
  128. his local net, and the source would in turn have to query the global     |
  129. database for the new forwarder address.  This scheme should also work if |
  130. hosts on both sides of a conversation are mobile and move                |
  131. simultaneously, although their change notices to each other may not get  |
  132. delivered, forcing them both to requery the database.                    |
  133.  
  134. ROUTING MESSAGES
  135.  
  136. This proposal requires a new kind of routing message carrying the name
  137. of a mobile host and the current forwarder (or forwarders) to use to
  138. reach it.  Such a message could serve either as a query (empty route
  139. portion); as an update to the global database, forwarders, and internet
  140. hosts; as a response to explicit queries to the database; or as an ACK
  141. to a current update (by repeating it).
  142.  
  143. Such a message fits conveniently within the current "gateway-gateway"
  144. protocol defined in IEN 109 [1].  There is already a similar type
  145. message in this protocol called "Redirect Message."  We propose adding a
  146. new message type called "Mobile Routing" as follows:
  147.  
  148.       Type: 11 (decimal) for Mobile Routing
  149.  
  150.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  151.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  152.       | Gateway Type  |   Operation   |  Route Count  |    unused     |
  153.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  154.       |                    Mobile Internet Address                    |
  155.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  156.       |                  Forwarder Internet Address                   |
  157.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  158.       /                                                               /
  159.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  160.       |                  Forwarder Internet Address                   |
  161.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  162.       |       Internet Header + 64 bits of Original Data Packet       |
  163.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  164.  
  165.          Gateway Type: 11
  166.  
  167.          Operation: 0 = Query
  168.                     1 = Update
  169.                     2 = Route Change Advisory
  170.  
  171.  
  172.  
  173. Sunshine & Postel                                               [Page 3]
  174.  
  175.  
  176.  
  177. IEN 135                                                       March 1980
  178. Addressing Mobile Hosts                                                 
  179.  
  180.  
  181.  
  182.                     3 = Acknowledge
  183.                     4 = Query Response
  184.  
  185.          Route Count: number of forwarder internet addresses included
  186.  
  187.          Mobile Internet Address: 32 bit internet address, typically
  188.          ABPR.xyz
  189.  
  190.          Forwarder Internet Address: 32 bit internet address
  191.  
  192.          Reference: present only for Op = 2 (route change advisory).
  193.                     Internet Header plus 64 bits of data from
  194.                     datagram causing this reply.
  195.  
  196.       Query messages will have a zero route count.
  197.  
  198.       Updates are used to update the global database or forwarder tables
  199.       when a host moves to a new net.
  200.  
  201.       Route Change Advisories are sent by a forwarder (or a mobile
  202.       destination) in response to the arrival of an internet datagram
  203.       that cannot (or soon will not be able to) be routed that way
  204.       anymore.  They include 64 bits of what is assumed to be the port
  205.       information from the higher level protocol in case the source
  206.       needs this to lookup the correct connection.
  207.  
  208.       Acknowledge datagrams are the responses to Updates so that the
  209.       sender of the Update knows it has been correctly received.  They
  210.       should repeat all the information in the original Update, simply
  211.       changing the OP from 1 to 3.
  212.  
  213.       Query Response is the answer to the Query datagram.
  214.  
  215. It is quite possible that a simple generalization of this message type
  216. could support general source route lookup from a routing database, but
  217. it is not our intention to pursue this avenue at this time.
  218.  
  219. The procedures for handling mobile hosts may also make use of the
  220. existing "Host Unreachable" message type.  Packets reaching an incorrect
  221. forwarder that cannot supply a new route to a mobile host (using the
  222. Route Change Advisory above) must return a simple Host Unreachable
  223. message, causing the source to query the global database.  If the reply
  224. to this query is the same forwarder, then the mobile host is truly
  225. unreachable.  The source may wish to wait a short time and requery the
  226. database on the hope that the mobile host is in process of moving to a
  227. new net.
  228.  
  229.  
  230.  
  231. Sunshine & Postel                                               [Page 4]
  232.  
  233.  
  234.  
  235. IEN 135                                                       March 1980
  236. Addressing Mobile Hosts                                                 
  237.  
  238.  
  239.  
  240. RELATION TO OTHER PROBLEMS
  241.  
  242. As stated in the introduction, there is some relation between the        |
  243. problems of mobile hosts and of dual-homed (on two networks) hosts.  In  |
  244. particular, one could consider dual-homed hosts as mobile, and go        |
  245. through the same route lookup and source routing procedures in           |
  246. communicating with them.  The dual-homed host itself could act as a      |
  247. degenerate sort of forwarder, receiving messages on either of its        |
  248. interface addresses, and "forwarding" them internally to its virtual net |
  249. address.  Presumably updates to the routing database would be made only  |
  250. when an interface  went down or up.  Dual-homed hosts would enjoy the    |
  251. same benefits of no changes to higher level protocols while messages     |
  252. could arrive over either interface.  However, the extra cost of route    |
  253. lookup, source routing, and assignment of a nework number, may not be    |
  254. justified for normal operation, and higher level procedures should still |
  255. be considered in this area.                                              |
  256.  
  257. There is also some relation to the network partition problem as follows.
  258. When a network partitions, we can treat the partitions as subnetworks,
  259. and the original host addresses as virtual network addresses where we
  260. don't know what (sub)network the host is located in.  Some dynamic
  261. mapping of host address to correct subnet must be performed, as in the
  262. mobile host case.  However, this situation requires the dynamic creation
  263. and deletion of new (sub)networks in the routing database, and hence
  264. goes beyond what we have proposed for mobile hosts.  We do not believe
  265. it is desirable to try and extend our proposal to cover this situation
  266. as well.
  267.  
  268. A simpler solution to the partitioning problem follows the spirit of
  269. querying a database when things go wrong.  Suppose there were another
  270. database listing networks and all the gateways attached to each net
  271. (whether up or down).  This database would change slowly only as new
  272. equipment was added to the internet system.  Further suppose that the
  273. gateways and internet routing are totally unaware of network partitions,
  274. except that gateways to partitioned nets find out when they cannot reach
  275. some host on their own net.  In this case, the gateway would return a
  276. Host Unreachable (through me) advisory message to the source.  The
  277. source could then query the global database to get a list of all
  278. gateways to the destination net, and construct explicit source routes to
  279. the destination going through each of these gateways, trying each one in
  280. turn until it succeeded.  The only difficulty in this scheme is that
  281. gateways should distinguish between hosts completely unreachable (so no
  282. rerouting will work) and those in a different partition.
  283.  
  284. This scheme assumes that there are few gateways to most nets (e.g. 2-4)
  285. and that partitions are a relatively rare event so that simple-minded
  286.  
  287.  
  288.  
  289. Sunshine & Postel                                               [Page 5]
  290.  
  291.  
  292.  
  293. IEN 135                                                       March 1980
  294. Addressing Mobile Hosts                                                 
  295.  
  296.  
  297.  
  298. polling is an adequate mechanism.  Compared to the approach suggested in
  299. IEN 120 [2], it requires some simple additional work at the source ONLY
  300. when partitions occur, but frees the gateways of all concern about
  301. partitions.  Given that partitions are a rare event, we think that a
  302. high level of effort by the gateways to make partitions "invisible" to
  303. the sources (even when no partitions exist) is not justified.  Both the
  304. scheme proposed here and the one in IEN 120 operate solely within the
  305. internet routing level and have no effect on higher level protocols.
  306.  
  307. SUMMARY
  308.  
  309. We have proposed a mechanism for allowing hosts to move between networks
  310. in the ARPA internet system without requiring any changes to protocols
  311. above the internet level.  The mechanism involves
  312.    1) the definition of a "virtual" net for mobile hosts,
  313.    2) the use of "forwarders" in each local net that can support
  314.       mobile hosts (much like the stations in packet radio nets), and
  315.    3) the use and maintenance of a global database giving the current
  316.       network location of mobile hosts.
  317.  
  318. We believe these three items are feasible with a modest amount of work
  319. because
  320.    1) is essentially an administrative matter,
  321.    2) is essentially already performed by stations on packet radio
  322.       nets, and
  323.    3) is similar to the name server function already implemented
  324.       experimentally.
  325.  
  326. We have also proposed a simple scheme for handling network partitioning
  327. based on trying explicit source routes to each gateway to the
  328. destination net when normal internet routing fails.
  329.  
  330. This proposal should be considered simply as outlining a promising
  331. approach.  Before elaborating further details, we would like your help
  332. in evaluating the overall ideas.  Comments to the authors are highly
  333. desired.
  334.  
  335. REFERENCES
  336.  
  337. [1]  Strazisar, V., "How To Build a Gateway", IEN 109, Bolt Beranek and
  338.      Newman Inc., August 1979.
  339.  
  340. [2]  Perlman, R., "Internet Routing and the Network Partition Problem",
  341.      IEN 120, Bolt Beranek and Newman Inc., October 1979.
  342.  
  343.  
  344.  
  345.  
  346.  
  347. Sunshine & Postel                                               [Page 6]
  348.