home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / inet / isoc / isocnews / issue1_3 / 040.15a < prev    next >
Encoding:
Text File  |  1993-02-08  |  4.9 KB  |  90 lines
  1. n-1-3-040.15  Dealing with Internet Growth - Internet Standards Activity
  2. by Craig Partridge <craig@aland.bbn.com>
  3.  
  4.     There are a number of technical trends coming together right now, all
  5. of which turn out to affect primarily IP (the internetwork layer protocol):
  6.  
  7.     (1) the explosive growth of the Internet is depleting the IP address
  8.         space -- so the address space in headers has to grow;
  9.  
  10.     (2) the explosive growth of the Internet is simultaneously stressing the
  11.         size of on routing tables for IP routers, and the general routing
  12.         architecture -- so the IP architecture for routing and addressing
  13.         needs to be revised to reduce routing stress;
  14.  
  15.     (3) DARPA-sponsored work on multimedia conferencing via IP is coming
  16.         of age (witness the delivery of the IETF plenaries to over
  17.         200 sites worldwide via the Internet last month) -- this
  18.         work is believed to eventually require some modification to IP
  19.         to support the provision of some form of performance guarantees
  20.         (for example, some of the sites on the IETF multicast experienced
  21.         delays of several seconds -- too long for comfortable conversation).
  22.  
  23. At the same time, there is no firm agreement on exactly when each of these
  24. trends will become critical to solve.  The IP class B address space is due
  25. to run out (I believe) next year, but there is an interim plan called CIDR
  26. which is supposed to get us past that problem (CIDR is completely transparent
  27. to hosts).  Exactly when CIDR will falter is unclear, but folks assume in
  28. a few years.
  29.  
  30. The routing table explosion seems more severe but again, timetables for
  31. disaster vary.  A couple of years, more or less, is a reasonable guess.
  32.  
  33. The multimedia work is still embryonic.  Complete proposals for architectural
  34. extensions to IP are not expected until early next year.  Agreement on what
  35. extensions work best is probably a couple years in the future.
  36.  
  37. Now, the key problem is timetable.  We need to develop addressing, routing
  38. and multimedia extensions good for an Internet of 100s of millions of hosts
  39. (perhaps billions). All three extensions are *hard* problems.  The IETF
  40. has been looking at addressing and routing for over two years (since some
  41. folks started graphing the address consumption curve and figured out doomsday
  42. was impending).  Folks have been looking at the multimedia problem for nearly
  43. a decade.  And these extensions must be tested thoroughly before launching
  44. them on the TCP/IP market.
  45.  
  46. The result is the following muddle.  To do serious testing and development of
  47. routing and addressing proposals, one needs to decide among the various
  48. proposal soon, in case worst-case predictions about
  49. addressing and routing stress come true.  So the IETF is pushing to try to
  50. make decisions by late this year.  Part of the motivation behind the IAB's
  51. Kobe announcement was a concern that the IETF was not moving fast
  52. enough.  At the same time, if the IETF decides too soon, it may have to
  53. revisit its decision when multimedia is ready to be added to the mix.
  54. But not enough is known about the exact form of the multimedia solution
  55. to factor it in now.  (Past experiences with guessing what is required have
  56. shown guessing is a bad idea).
  57.  
  58. There are currently four proposals before the IETF:
  59.  
  60.     TUBA -- a proposal to replace IP with CLNP (ISO connection-less
  61.         internetwork layer protocol).  CLNP has bigger address fields than
  62.         IP but is otherwise architecturally similar to IP.  The most common
  63.         gripe about TUBA is that it probably causes the greatest amount of
  64.         code to change (because the packet format is completely different,
  65.         even if the functionality is the same) and that while the addresses
  66.         get bigger, the larger addressing and routing problems aren't
  67.         addressed.  The TUBA proposal can be found in RFC 1347.
  68.  
  69.     Nimrod -- a more radical proposal by Noel Chiappa.  Yet to be fully
  70.         committed to paper but to be taken seriously as Noel is an
  71.         acknowledged wizard in routing and addressing.  Noel believes
  72.         that he can avoid changes to host software yet provide the
  73.         extensibility in routing necessary to support multimedia.
  74.         It is hard to assess the proposal fully.
  75.  
  76.     PIP -- a proposal by Paul Tsuchiya, another acknowledged wizard.
  77.         It is available as two Internet drafts 
  78.         (draft-tsuchiya-pip-00.txt, draft-tsuchiya-pip-overview-01.txt)
  79.  
  80.     IPAE -- a proposal to encapsulate larger IP addresses within a sub-layer
  81.         above IP.  Has the merit that hosts can function unchanged in
  82.         most situations, and may require the least modification to existing
  83.         code.  Major concern is that non-upgraded hosts will exist in
  84.         disjoint islands of IP, which cannot communicate with each other.
  85.         Available as an Internet draft (draft-crocker-ip-encaps-00.txt)
  86.  
  87. It is expected the IETF will be deciding among these proposals at the end of
  88. the year.
  89.  
  90.