home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 94jul / ipngwg-minutes-94jul.txt < prev    next >
Text File  |  1994-11-01  |  7KB  |  186 lines
  1.  
  2. IPNG Working Group BOF (IPNGWG)
  3.  
  4. Reported by Scott Bradner/Harvard University
  5.  
  6. This BOF allowed a number of folks to give ten minute presentations on
  7. issues of concern.
  8.  
  9.  
  10. Dave Sincoskie
  11.  
  12. Dave is concerned about tunneling (encapsulation).  This is a good
  13. technique for quick implementation of low usage service.  However, this
  14. tends to result in difficulty debugging networks (an organization which
  15. offers underlying service does not know about higher level service,
  16. therefore does not know how to fix it).  This implies price and quality
  17. of service problems.
  18.  
  19. What does this have to do with addressing?  The issue with addressing
  20. is:  What are the problems that we are trying to solve?  If the proposed
  21. solution to some addressing/routing issues is to use encapsulation, then
  22. we need to understand whether there are problems with this approach.
  23. The Internet might become the Global Information Infrastructure---we do
  24. not want to do this through a mechanism which we know is broken (e.g.,
  25. for support of mobility).
  26.  
  27.  
  28. Peter Ford
  29.  
  30. What do we know how to do:  Datagram networking with source/destination
  31. addresses; speed matters; longest prefix match; some kind of source
  32. routing is likely to be used.  Addresses are used in a variety of ways
  33. (private networks, local versus global traffic, source routing through
  34. mesh of providers, etc.).  This implies a need for flexible address
  35. support.  End system unicast addresses (global and local addresses);
  36. routing domain identifiers/addresses; multicast addresses.
  37.  
  38. What we do not know:  How big the network will get; what we are actually
  39. addressing; the ``shape'' of addresses (internal structure, number of
  40. levels); what are we really trying to represent (semantic overload of
  41. field).
  42.  
  43. Variable length addresses means add flexibility and extensibility.  What
  44. is maximum size (16 bytes, 32 bytes, larger)?
  45.  
  46. We need to support cluster addresses (addresses for groups of things)
  47. and local addresses.
  48.  
  49. There is a controversy regarding whether 16 bytes is enough.  In fact we
  50. just do not know whether 16 bytes is enough or not.
  51.  
  52. The cost of flexibility is small.  Variable length addressing (with
  53. sufficient max) ensures that we will not run out, and also allows
  54. smaller addresses, therefore better efficiency.
  55.  
  56.  
  57. John Wroclawski
  58.  
  59. Two things can happen:  We can take over the world, we can be a ``lingua
  60. franca'' over other things (he left out the third possibility, IPng
  61. could fail).
  62.  
  63. Low cost is important (cost to manufacture a telephone is $10; set-top
  64. box is $50).  Management of link latency (delay and variance of delay)
  65. is important.  Real and perceived performance:  Has to work well, press
  66. has to perceive that it will work well.  Efficient datagrams we do well.
  67. Efficiency for streams of datagrams not so well.
  68.  
  69. This implies that support for flow labels needs to be required.  We need
  70. to do something about header compression, and not only on slow links.
  71.  
  72. We do not do management of latency.  This is a deficiency.  Jumbograms
  73. make this worse (bigger MTU has a big effect on this).
  74.  
  75.  
  76. Matt Mathis
  77.  
  78. Wants explicit support for lightweight (compressed) headers; header
  79. compression in stream mode; and Jumbograms in order to make TCP work
  80. well at very high speeds (OC12 or 48 over WAN). (Van Jacobsen thinks
  81. that jumbograms are broken---avoiding this requires some tweaks to TCP.
  82. It was suggested that header compression might not be hop-by-hop.
  83. Another suggestion was that addresses not be in every packet).
  84.  
  85.  
  86. Paul Francis
  87.  
  88. Paul is concerned about addressing issues related to connecting to
  89. providers:  changing providers, multiple providers, no provider.
  90.  
  91. Basic form of address is:  ``interdomain-prefix'' plus ``private part.''
  92. The private part must have a guaranteed space no matter which provider,
  93. this needs to be specified.  Paul questions whether or not 8 bytes is
  94. enough for the private part.
  95.  
  96. Provider-routed versus geographical addresses:  If you have provider
  97. routed addresses, then the inter-domain prefix indicates the provider.
  98. This implies that each provider needs to be internally connected.  If
  99. you have pure geographic addresses, then the geographic areas have to be
  100. connected (implying that multiple providers have to
  101. cooperate/``connect'').  There are tricky problems related to this
  102. connection.
  103.  
  104. Provider-based addresses are nice for providers, and hell for
  105. subscribers.  Geographic addresses are hell for providers, and nice for
  106. subscribers.  Provider selection implies that you have to have something
  107. in the packet which tells you which provider, which seems to imply
  108. provider-based addresses.  Geographic addresses forces connectivity
  109. between providers in every geographic area.
  110.  
  111. Paul thinks that we should experiment with geographic addresses.
  112.  
  113.  
  114.  
  115. Brian Carpenter
  116.  
  117. We need to be able to map other address spaces into the IPng address
  118. space.  Proposes how to map NSAP addresses into IPng.  Point is that we
  119. need to do this, and 16 bytes is sufficient to do so.  The point of this
  120. is to make use of existing addressing plans.  ``The applicability
  121. statement would be a delicate piece of text.''
  122.  
  123.  
  124.  
  125. Steve Bellovin
  126.  
  127. There is a need for multiple addresses per host.  This may be used for
  128. multiple services on the same host.  Permanent (location-independent)
  129. and temporary (location-dependent) addresses.  Different addresses for
  130. billing (bill to address).  An ``ARP-replacement'' should not preclude
  131. having a moderately large number of addresses per host.
  132.  
  133.  
  134.  
  135. Noel Chiappa
  136.  
  137. Noel presented ``Topologically Sensitive Names for Routing in Very Large
  138. Networks; or, Why I like Variable Length Addresses.''
  139.  
  140. Hierarchy is the only way that we know to allow routing to scale.
  141. Hierarchical names are sequences of area ``names.''  In order for
  142. routing to scale, the addressing must correspond to the hierarchical
  143. topology.
  144.  
  145. In a decentralized net, there will be a variation in tree depth.  For
  146. quality of service or policies, there may be more layers of hierarchy.
  147.  
  148. Thus, what we are doing is representing an essentially variable length
  149. thing in a fixed length field.  In order to do this, we need to have a
  150. very good crystal ball.  However, we just do not have a good enough
  151. crystal ball.
  152.  
  153. Summary:  Variable length topologically sensitive addresses is the
  154. natural state of things.  We should think about how to make this work
  155. well, and not try to fit things into a fixed length field.
  156.  
  157.  
  158. Bill Simpson
  159.  
  160. Bill is concerned with requirements for mobility.  We spend a lot of
  161. time niggling bits and bytes to make the headers smaller because the
  162. bandwidth of the mobile links is severely limited.  Concerned that
  163. mobile node users will perceive performance degradation if headers are
  164. too big.
  165.  
  166. Bill used the ``two to the n'' argument (assuming relatively dense
  167. packing) implying that we do not really need large addresses.  Extra
  168. hierarchical levels should be minimized (use where necessary for
  169. routing, not when unnecessary).  Encapsulation (e.g., for mobility)
  170. implies two headers which implies still more concern about header size.
  171. We cannot make the slow mobile links faster (international treaties,
  172. frequency allocation).
  173.  
  174.  
  175. Larry Wolf
  176.  
  177. Larry is concerned about address allocation issues:  They have found
  178. address allocation to be very time consuming and expensive.
  179.  
  180. Do not expect more than 64K hosts per subnet.  Propose a fixed address
  181. boundary for subnet/host.
  182.  
  183. Larry proposed that we should charge for addresses (if you are willing
  184. to pay, then you do not need to explain why you need the addresses).
  185.  
  186.