GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien165

USC / ISI Danny Cohen 3 January 1981 Jon Postel W-note-23 Steve Casner IEN-165

                   About addressing in the WBnet
                   -----------------------------

This note is written in response to W-note-16 (aka IEN-162, by John Pershing) about a proposed addressing scheme for the WBnet.

We found the above note to be very well written, and it points out a very difficult problem in internetwork addressing; however, we beg to differ with some of the underlying assumptions, and therefore have arrived at another proposal.

In this note we will first review the W-16 proposal, then present ours and compare the two approaches.

                         The W-16 approach
                         -----------------

Assumptions and objectives:

  1. Whichever addressing scheme is used had better be compatible

with IP.

  1. There is a rich structure interconnecting hosts at all the

sites which are connected to the WBnet. This richness is

   beyond what the processing nodes of the WBnet can be  expected
   to  process  directly  -  hence  a  hierarchical  structure is
   proposed.
  1. The richness of all the host interconnections at all sites

combined is similar to that of the catenet - hence a similar

   solution should work.
  1. "To hide the physical structure of the Wideband Net from the

Internet and its gateways" - quoted from W-16.

  1. "To unify the transport and routing functions performed within

the Wideband Net" - quoted from W-16. 2

This yields the following addressing scheme:

Consider ALL the hosts on the ALL the local-nets which are connected to ALL the WBnet gateways as being WBnet hosts, and assign them WBnet addresses which reflect their connectivity to the WBnet as shown below:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      28.      | Subnet Number |    Reserved for Subnet Use    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      8-bits          8-bits                 16-bits

For example, if there are 4 Lexnets and one Voice Funnel, at some site, then each of these 5 "things" is assigned its own subnet-ID.

We hope that the above is an accurate reflection of the proposal as put forth in W-16.

                          The ISI approach
                          ----------------

We, too, believe that there may be a rich structure of host interconnections at each site. However, for the time being we expect the number of hosts at each site to be small enough that 8 bits would suffice for intra-site addressing.

We also believe that all of our hosts are constituents of the catenet, not of any particular network, including the WBnet. By this we mean that any host should be addressable via any of the catenet networks to which it has a connection.

We would like to reserve 8 bits of the WBnet/IP address for local addressing so that each host can be assigned a single local address. This local address would remain constant independent of which gateway or directly-connected host (if any) was being used as an intermediary.

Therefore, we propose that only 16-bit WBnet addresses be assigned to hosts which are connected to PSATs, directly or through some transparent "port-expanding" mechanism such as a Voice Funnel. These hosts are either bona fide hosts or full fledged IP (and/or ST) gateways.

At ISI, for example, we will have probably one or two such hosts, through which all the other hosts gain access to the WBnet.

We prefer to see IP (and/or ST) gateways, not WBnet gateways, playing the various intra-site communication roles (like routing) regardless of which transport mechanism was used to get to the site, either Satellite or terrestrial lines. 3

Therefore we prefer the following addressing scheme:

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Any Network  |    Addressing in that net     | Local address |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      8-bits                 16-bits                   8-bits

This allows traffic for any host at a site to arrive through any existing gateway.

The details associated with the routing of intra-site traffic do not have to be propagated outside that site.

                  Comparison of the two approaches
                  --------------------------------

We acknowledge that our approach has the severe limitation that it can currently support only up to (about) 256 hosts per site. Please note, this is a restriction on the number of hosts but not necessarily on the number of voice terminals, since NVP provides another level of addressing called "extensions".

We propose that when this limit is reached an extended addressing scheme (along the lines of source routing) be used.

The W-16 proposal requires that WBnet-gateways be installed between all the local networks in every site. It requires that any change in connectivity of the local networks be propagated to all the WBnet gateways, in all the other sites, and be stored in all of them. This, in our opinion, does not really comply with spirit of hiding local details from the global world, as stated as one of the objectives of the scheme.

We believe that our proposal meets the objectives stated at the beginning of this note, at least as much as the W-16 proposal. Especially it meets the requirement that the details of intra-site communication are no one else's business. We think that as far as the outside world is concerned there is no difference between using hosts for port-expanding and using local networks, or any hybrid of these approaches.

The W-16 scheme must know all about the intra-site communication structure. This scheme also requires the development (and implementation) of a Gateway/Gateway protocol, just as was done for the catenet.

It is not clear to us at all why all of our hosts should pledge their allegiance to W-16 addressing scheme and to the WBC for which it stands, one network, indivisible (enough!!).

We would like to treat the WBnet just as another transport mechanism, which should be used only when it is found to be the best alternative for some communication requirements. For our communication system the WBnet should be just another means of inter-site communication, not a religion to which all of our internal gateways and bridges have to subscribe. 4

                             Conclusion
                             ----------

We recommend that only 16-bit addresses be used within the WBnet in order to specify its hosts; and that these hosts be either bona fide hosts or gateways into other networks, including intra-site communication systems.

As long as intra-site addressing can be handled by an 8-bit field there is an efficient and convenient way to incorporate this field within the IP-address field in addition to the 16-bit WBnet addresses.

                         Referee's comment
                         -----------------

Under the assumption that 8-bit addressing is enough for all intra-site addressing, and under the assumption that all the local networks at any site share this address space and already are capable of communicating among themselves (and do not need help from the WBnet in order to achieve it) - the two approaches, W-16 and ISI's, are IDENTICAL.

The folks at BBN may treat each site as a single subnet and assign it a single subnet-ID. On the other hand, the folks at ISI may assign unique local addresses to each of their hosts.

Hence, the 32-bit IP-address of the host on the WBnet will be composed of the following 4 bytes (in Big-Endian's order, obviously):

Byte#0 = 28., the net-ID of the WBnet,      assigned by Postel.
Byte#1 = WBnet address: Site- or Subnet-ID, assigned by BBN.
Byte#2 = Reserved for future extensions
Byte#3 = Local address,                     assigned by each site.

We would also like to recommend that BBN assign the subnet-ID's in bit-reversed order in order to maintain maximal flexibility for future expansions which may occur at either end of the addressing scheme.

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien165.txt · Last modified: 2001/06/25 19:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki