GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc730

RFC 730 20 May 77 Extensible Field Addressing

Network Working Group Jon Postel Request for Comments: 730 USC-ISI NIC: 40400 20 May 1977

                    Extensible Field Addressing

Introduction

This memo discusses the need for and advantages of the expression of addresses in a network environment as a set of fields. The suggestion is that as the network grows the address can be extended by three techniques: adding fields on the left, adding fields on the right, and increasing the size of individual fields. Carl Sunshine has described this type of addressing in a paper on source routing [1].

Motivation

Change in the Host-IMP Interface

The revised Host-IMP interface provides for a larger address space for hosts and IMPs [2]. The old inteface allowed for a 2 bit host field and a 6 bit IMP field. The new interface allows a 8 bit host field and a 16 bit IMP field. In using the old interface it was common practice to treat the two fields as a single eight bit quantity. When it was necessary to refer to a host by number a decimal number was often used. For example host 1 on IMP 1 was called host 65. Doug Wells has pointed out some of problems associated with attempting to continue such useage as the new interface comes into use [3]. If a per field notation had been used no problems would arise.

Some examples of old and new host numbers are:

Host Name       Host IMP old #   new #
--------------------------------------
SRI-ARC            0   2     2       2
UCLA-CCN           1   1    65   65537
ISIA               1  22    86   65558
ARPA-TIP           2  28   156  131100
BBNA               3   5   197  196613

Multinetwork Systems

The prospect of interconnections of networks to form a complex multinetwork system poses additional addressing problems. The new Host-IMP interface specification has reserved fields in the leader to

Postel [page 1]

RFC 730 20 May 77 Extensible Field Addressing

carry network addresses [2]. There is experimental work in progress on interconnecting networks [4, 5, 6]. We should be prepared for these extensions to the address space.

The addressing scheme should be expandable to increase in scope when interconnections are made between complex systems.

Multiprocessor Hosts

There may be configurations of hardware that could be interfaced to a network as a single host that in fact contain multiple processors. Tasks could be associated with processors such that it is desirable to dispatch network messages associated with certain sockets or message-ids to certain processors. For example it might be desirable to service all Telnet use from one processor and all FTP use from a different processor.

The addressing scheme should be expandable to explicitly address the fine structure within a host when that is desirable.

Some examples where such fine structure addressing would have been useful in the ARPANET are:

At ISI, we have the capability of emulating computers using the PRIM
system [7].  For many applications it is desirable to add the emulated
host to the network.  Since the emulation is carried out under control
of a program operating under Tenex, we have a host within a host.
Extensible addressing of hosts would provide the necessary handle.
SCRL once had a PDP-11 connected by VDH to an IMP at UCSB.  It became
necessary to add a second PDP-11 to the network.  The two PDP-11s were
already physically connected and it would have been a simple matter to
have the first serve as a multiplexor for both.  However, because of
the limitations in the network addressing structure, there was no way
to identify the two hosts to other sites on the network.  A new IMP
had to be installed!
In many other cases, it is desirable to have two hosts share the same
front end to the network.  With the current limitation, one IMP port
must be consumed for each host.

Postel [page 2]

RFC 730 20 May 77 Extensible Field Addressing

Proposal

The necessary solution to the problem posed by the change in the Host-IMP inteface is to always represent the address by fields. This solution provides for a natural growth into an internetwork environment, and allows explicit addressing of the fine structure within a host if that is desirable.

The fields should be written in a natural way, and i believe that means that the most general field should come first with additional fields specifying more and more details of the address. In the current case this would lead to the following fields:

Network / IMP / Host / Message-Identifier

A problem with simple field addressing is the desire to specify only the fields that are necessary given the local context. A program interpreting the address is then unsure what the first field represents. Some clues are needed in the address specification for correct parsing to be possible. Dave Crocker has described a syntax for a similar problem in network access of data [8].

Specific Sugestion

Specifically i suggest that we adopt a field based extensible address scheme where each field is separated from its neighbors by a delimiter character and each field has a name. When an address is specified the name of the most general field must also be indicated.

Definitions:
  <address> ::= <field-name> ":" <fields>
  <field-name> ::= "NET" | "IMP" | "HOST" | "MESSAGE-ID"
  <fields> ::= <field> | <field> "/" <fields>
  <field> ::= a decimal number
Examples:
  NET:1/3/5/7  names message-id 7 at host 5 on imp 3 in network 1.
  HOST:6  names host 6 on whatever imp this message originates on.

Postel [page 3]

RFC 730 20 May 77 Extensible Field Addressing

One might ask: What is all the fuss about, isn't this a non-problem?, The answer is: Almost. There are very few places where any real difficulties arise, but we have to change the way we think about host addresses. The places where there is a problem are typically little used, except one. The place where humans will see a difficulty is in the TIP "open" command [9], and to a lesser extent the user Telnet and user FTP "connect" commands. Other places are in the MAIL netaddress field, the FTP "sock" command [10], the Telnet reconnection option [11], and in the NIC maintained list of official host names [12].

Conclusion

The suggestion is that we adopt field based extensible addressing to provide for growth in three ways:

(1) growth of the number of hosts and IMPs by allowing these fields to grow in size independently of each other;

(2) growth in scope by the addition of fields on the left to provide for multinetwork systems;

(3) growth in fine structure by addition of fields on the right for the implementation of hosts as mininetworks.

Postel [page 4]

RFC 730 20 May 77 Extensible Field Addressing

References

[1] Sunshine, C. "Source Routing and Computer Networks," Computer

      Communication Review, Vol. 7, Number 1, ACM Special Interest
      Group on Communications (SIGCOMM), January 1977.  Also
      circulated as INWG General Note number 133.

[2] BBN, "The Interconnection of a Host and an IMP," Report 1822,

      Bolt Beranek and Newman, Revised January 1976.

[3] Wells, D., "Impact of New IMP Leaders on Higher-level

      Protocols," ARPA Network Message
      [MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 May 1977.

[4] Beeler, et.al. "Gateway Design for a Computer Network

      Interconnection," PRTN 156, February 1976.

[5] Cerf, V., Y. Dalal, and C. Sunshine. "Specification of an

      Internet Transmission Control Program," INWG General 72, RFC
      675, Revised December 1974.

[6] Cerf, V. "Specification of TCP version 2," March 1977.

[7] Britt, B. et.al. "PRIM System: Overview," ISI/RR-77-58,

      Information Sciences Institute, University of Southern
      California, March 1977.

[8] Crocker, D., "Network Standard Data Specification Syntax," RFC

      645, Network Information Center Catalog Number 30899, 27 June
      1974.

[9] Malman, J., "User's Guide to the Terminal IMP," Report 2138,

      Bolt Beranek and Newman, Network Information Center Catalog
      Number 10916, Revised March 1976.

[10] Neigus, N., "File Transfer Protocol," RFC 542, Network

      Information Center Catalog Number 17759, 12 August 1973.
      Contained in "ARPANET Protocol Handbook," Network Information
      Center Catalog Number 7104, Revised 1 April 1976.

[11] Thomas, R., "Telnet Reconnection Option," Network Information

      Center Catalog Number 15391, August 1973. Contained in "ARPANET
      Protocol Handbook," Network Information Center Catalog Number
      7104, Revised 1 April 1976.

[12] [Offfice-1]<NETINFO>HOSTS.TXT

Postel [page 5]

/data/webs/external/dokuwiki/data/pages/rfc/rfc730.txt · Last modified: 1992/10/15 21:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki