home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ien / ien-165 < prev    next >
Text File  |  1988-12-02  |  9KB  |  196 lines
  1.  
  2. USC / ISI                                                    Danny Cohen
  3. 3 January 1981                                                Jon Postel
  4. W-note-23                                                   Steve Casner
  5. IEN-165
  6.  
  7.  
  8.                      About addressing in the WBnet
  9.                      -----------------------------
  10.  
  11. This  note is  written  in response to W-note-16  (aka IEN-162,  by John
  12. Pershing) about a proposed addressing scheme for the WBnet.
  13.  
  14. We  found  the  above  note to be very well written, and it points out a
  15. very difficult problem in internetwork addressing; however,  we  beg  to
  16. differ  with  some  of  the  underlying  assumptions, and therefore have
  17. arrived at another proposal.
  18.  
  19. In this note we will first review the W-16 proposal, then  present  ours
  20. and compare the two approaches.
  21.  
  22.  
  23.                            The W-16 approach
  24.                            -----------------
  25.  
  26. Assumptions and objectives:
  27.  
  28.    - Whichever  addressing  scheme is used had better be compatible
  29.      with IP.
  30.  
  31.    - There is a rich structure interconnecting  hosts  at  all  the
  32.      sites  which  are  connected  to  the WBnet.  This richness is
  33.      beyond what the processing nodes of the WBnet can be  expected
  34.      to  process  directly  -  hence  a  hierarchical  structure is
  35.      proposed.
  36.  
  37.    - The richness of all the host  interconnections  at  all  sites
  38.      combined  is  similar to that of the catenet - hence a similar
  39.      solution should work.
  40.  
  41.    - "To hide the physical structure of the Wideband Net  from  the
  42.      Internet and its gateways" - quoted from W-16.
  43.  
  44.    - "To unify the transport and routing functions performed within
  45.      the Wideband Net" - quoted from W-16.
  46.                                    2
  47.  
  48. This yields the following addressing scheme:
  49.  
  50. Consider  ALL the hosts on the ALL the local-nets which are connected to
  51. ALL the WBnet gateways as being  WBnet  hosts,  and  assign  them  WBnet
  52. addresses which reflect their connectivity to the WBnet as shown below:
  53.  
  54.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  55.    |      28.      | Subnet Number |    Reserved for Subnet Use    |
  56.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  57.         8-bits          8-bits                 16-bits
  58.  
  59.  
  60. For  example, if there are 4 Lexnets and one Voice Funnel, at some site,
  61. then each of these 5 "things" is assigned its own subnet-ID.
  62.  
  63. We hope that the above is an accurate reflection of the proposal as  put
  64. forth in W-16.
  65.  
  66.  
  67.                             The ISI approach
  68.                             ----------------
  69.  
  70. We,   too,   believe  that  there  may  be  a  rich  structure  of  host
  71. interconnections at each site.  However, for the time  being  we  expect
  72. the  number  of  hosts at each site to be small enough that 8 bits would
  73. suffice for intra-site addressing.
  74.  
  75. We also believe that all of our hosts are constituents of  the  catenet,
  76. not  of  any  particular  network, including the WBnet.  By this we mean
  77. that any host should be addressable via any of the catenet  networks  to
  78. which it has a connection.
  79.  
  80. We  would  like  to  reserve  8  bits  of the WBnet/IP address for local
  81. addressing so that each host can be assigned  a  single  local  address.
  82. This local address would remain constant independent of which gateway or
  83. directly-connected host (if any) was being used as an intermediary.
  84.  
  85. Therefore,  we  propose  that only 16-bit WBnet addresses be assigned to
  86. hosts which are connected to PSATs, directly or through some transparent
  87. "port-expanding" mechanism such as  a  Voice  Funnel.  These  hosts  are
  88. either bona fide hosts or full fledged IP (and/or ST) gateways.
  89.  
  90. At  ISI,  for  example,  we  will  have  probably one or two such hosts,
  91. through which all the other hosts gain access to the WBnet.
  92.  
  93. We prefer to see IP (and/or ST) gateways, not  WBnet  gateways,  playing
  94. the  various intra-site communication roles (like routing) regardless of
  95. which transport mechanism was used to get to the site, either  Satellite
  96. or terrestrial lines.
  97.                                    3
  98.  
  99. Therefore we prefer the following addressing scheme:
  100.  
  101.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  102.    |  Any Network  |    Addressing in that net     | Local address |
  103.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  104.         8-bits                 16-bits                   8-bits
  105.  
  106. This  allows  traffic  for  any  host  at  a  site to arrive through any
  107. existing gateway.
  108.  
  109. The details associated with the routing of  intra-site  traffic  do  not
  110. have to be propagated outside that site.
  111.  
  112.  
  113.                     Comparison of the two approaches
  114.                     --------------------------------
  115.  
  116. We  acknowledge  that our approach has the severe limitation that it can
  117. currently support only up to (about) 256 hosts per site.   Please  note,
  118. this  is a restriction on the number of hosts but not necessarily on the
  119. number  of  voice  terminals,  since  NVP  provides  another  level   of
  120. addressing called "extensions".
  121.  
  122. We propose that when this limit is reached an extended addressing scheme
  123. (along the lines of source routing) be used.
  124.  
  125. The  W-16 proposal requires that WBnet-gateways be installed between all
  126. the local networks in every site.    It  requires  that  any  change  in
  127. connectivity  of  the  local  networks  be  propagated  to all the WBnet
  128. gateways, in all the other sites, and be stored in all of them. This, in
  129. our opinion, does not really comply with spirit of hiding local  details
  130. from the global world, as stated as one of the objectives of the scheme.
  131.  
  132. We  believe  that  our  proposal  meets  the  objectives  stated  at the
  133. beginning of  this  note,  at  least  as  much  as  the  W-16  proposal.
  134. Especially  it  meets  the  requirement  that  the details of intra-site
  135. communication are no one else's business.  We think that as far  as  the
  136. outside  world  is  concerned there is no difference between using hosts
  137. for port-expanding and using local networks,  or  any  hybrid  of  these
  138. approaches.
  139.  
  140. The  W-16  scheme  must  know  all  about  the  intra-site communication
  141. structure.    This   scheme   also   requires   the   development   (and
  142. implementation)  of a Gateway/Gateway protocol, just as was done for the
  143. catenet.
  144.  
  145. It is not clear to us at all why all of our hosts  should  pledge  their
  146. allegiance to W-16 addressing scheme and to the WBC for which it stands,
  147. one network, indivisible (enough!!).
  148.  
  149. We  would  like  to treat the WBnet just as another transport mechanism,
  150. which should be used only when it is found to be  the  best  alternative
  151. for  some  communication requirements.  For our communication system the
  152. WBnet should be just another means of inter-site  communication,  not  a
  153. religion  to  which  all  of  our  internal gateways and bridges have to
  154. subscribe.
  155.                                    4
  156.  
  157.  
  158.                                Conclusion
  159.                                ----------
  160.  
  161. We  recommend  that  only  16-bit  addresses be used within the WBnet in
  162. order to specify its hosts; and that these hosts  be  either  bona  fide
  163. hosts   or   gateways   into   other   networks,   including  intra-site
  164. communication systems.
  165.  
  166. As long as intra-site addressing can be handled by an 8-bit field  there
  167. is  an efficient and convenient way to incorporate this field within the
  168. IP-address field in addition to the 16-bit WBnet addresses.
  169.  
  170.  
  171.  
  172.                            Referee's comment
  173.                            -----------------
  174.  
  175. Under the assumption that 8-bit addressing is enough for all  intra-site
  176. addressing,  and under the assumption that all the local networks at any
  177. site share this address space and already are capable  of  communicating
  178. among  themselves  (and  do  not  need  help  from the WBnet in order to
  179. achieve it) - the two approaches, W-16 and ISI's, are IDENTICAL.
  180.  
  181. The folks at BBN may treat each site as a single subnet and assign it  a
  182. single subnet-ID.  On the other hand, the folks at ISI may assign unique
  183. local addresses to each of their hosts.
  184.  
  185. Hence,  the  32-bit IP-address of the host on the WBnet will be composed
  186. of the following 4 bytes (in Big-Endian's order, obviously):
  187.  
  188.   Byte#0 = 28., the net-ID of the WBnet,      assigned by Postel.
  189.   Byte#1 = WBnet address: Site- or Subnet-ID, assigned by BBN.
  190.   Byte#2 = Reserved for future extensions
  191.   Byte#3 = Local address,                     assigned by each site.
  192.  
  193. We would also like to recommend  that  BBN  assign  the  subnet-ID's  in
  194. bit-reversed  order  in order to maintain maximal flexibility for future
  195. expansions which may occur at either end of the addressing scheme.
  196.