IEN 171 Danny Cohen USC / ISI 18 January 1981 Addressing in the ARPAnet, another visit ---------------------------------------- As you all remember the addressing in the HOST/IMP interface for the ARPAnet has the following format (as defined in 1822): 8 8 16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |///IP-net-ID///| H O S T | I M P | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9 16 41 48 49 64 Please allow me to take the liberty of showing it in a more "logical" and consistent order: 8 16 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |///IP-net-ID///| I M P | H O S T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the rest of this discussion we will use only this "logical" order. It is well known that for the time being the Net-ID field is not used and that IMP numbers may be contained in a single 8-bit field. Therefore, ARPAnet addresses are of the form: 8 8 8 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |///IP-net-ID///| I M P | 0 | H O S T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 I believe that a single 8-bit field for the IMP address may be found in a (relatively) near future to be too restrictive. Let's assign a 12-bit field for this purpose (even though I believe that 10 are enough). Using 12 bits for IMP-addressing the following format is suggested: 8 12 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |///IP-net-ID///| I M P | H O S T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hence, I propose an arrangement which will allows a connection of up to 4,096 hosts to a single IMP (out of 4,096), or more hosts out of less IMPs if the IMP-address field is chosen to be smaller than 12 bits. One of the best ways to connect many hosts to an IMP at any site is by contracting BBN to provide that many IMP/HOST interfaces. Another way is by sharing a few IMP ports by several hosts, by using multiplexers, port-expanders or other multi-access schemes. One candidate technology for such multiplexing is the one commonly referred to as "local networks". I advocate that the details of this arrangement are of interest only of that site, and are no one else's business. In other words, these details do not have to be made available outside of that site. The word HOST in all of the above diagrams is most misleading. The IMP has absolutely no notion of host. All it knows is which port is used. This field is used to identify the IMP port, not the HOST. It is proposed here that if there are several hosts sharing the same port, then a HOST-ID field should follow the PORT-ID field. How big should these two fields (the PORT-ID and the HOST-ID) be? The answer depends on the local configuration at each site. One site may chose to connect its 64 hosts by using 64 ports bought from BBN, another by using a smaller number of ports each supporting several hosts through some port expanders, and another site may connect all of its 64 host through a single port. Obviously, hosts which share the same ports have to understand the advantages and disadvantages which are associated with this sharing, such as the flow-control which is based on port-pair, port blocking, etc. It is not unreasonable to expect the personnel at each site to be intelligent enough to understand these issues and to make the appropriate decision about it, as best suits the particular situation. The notion which is advocated here is that the distinction between PORT-ID and HOST-ID does not have to be known and understood to the outside, just as on the ARPAnet the distinction between the IMP-ID and the HOST-ID does not have to be understood even at the HOST/HOST protocol level. 3 Again, where does the proposed PORT-ID field end and the HOST-ID start? One possible approach is to legislate the same answer for all IMPs, regardless of the particular situation of each one. This has some trivial simplification benefits. Another is to follow the IP philosophy of NOT legislating the format of each intranet addressing, and leaving it as the "REST" which has to be understood only at the local environment for which it is designed. Following this philosophy it is proposed that the PORT-ID field be defined to be of a variable length, defined specifically for each IMP according to the local requirements which it has to support. Let N(i) be the length PORT-ID field at IMP(i), i.e., the IMP whose ID is i. Hence, once a message arrives at IMP(i) for any of its hosts, this IMP should look at the top N(i) bits of the PORT-ID/HOST-ID field and extract the PORT-ID for the port to be used for forwarding this message. Neither the extra processing nor the storage requirements for supporting this scheme seem to be excessive. Obviously there must be some processor on the other end of every port which is capable of handling the required handshake with the IMP. The flow control which is now based on port/port pairs must be somehow modified since the notion of remote port does not exist under this proposal. Without getting into details here we suggest that this problem can be solved, and the difficulties associated with this modification are outweighed by the benefits of this scheme. The main advantage of such a scheme, in comparison with having some kind of a gateway (or equivalent, such as SRI's port-expander) is that the forwarding may take place in a very efficient way without the need to "open each envelop", understand the protocol used, finding the full IP-address (whose position may vary even for different versions of IP) and decipher from it where to forward the message. The author of this short note dares suggest that efficiency is not a sign of moral turpitude and that we should be as efficiency oriented as possible. Hence, our proposed format for the ARPAnet addressing is: 8 12 N(i) / 12-N(i) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |///IP-net-ID///| I M P | P O R T / H O S T | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format is "logical" and suggestive only. It is well understood that these bits may be packed in a different order and over several non-consecutive fields (e.g., 9-16 and 41-64). 4 A problem with the current 1822 format -------------------------------------- The basic notion of 1822 is that it is a IMP/HOST protocol. Unfortunately, 1822 is the IMP/PORT (or IMP/INTERFACE) protocol. If every PORT always supports only one host then 1822 is really an IMP/HOST protocol. However, with today's technology where hosts range in size (and cost) over several orders of magnitude it is not unreasonable to expect that several hosts share a single IMP-PORT. This may be accomplished in a variety of ways which we better not discuss here since this is too rich topic for this discussion. Most modern protocols carry both the TO: and the FROM: addresses across the "subscriber" interface. It would be nice, and most helpful, if 1822 would carry both the destination and the source addresses, just like IP, TCP, PUP and Ethernet - to name a few. Background (or why we, at ISI, like this scheme) ------------------------------------------------ I apologize for introducing the motivation at the end of the note, rather than at its beginning. At ISI any scheme which would allow a fast and efficient packet multiplexing between many hosts and networks is a cornerstone of the architecture of our new environment. We, at ISI, would like to be able to multiplex packets with minimal processing and without the need to "open each envelop" and read the "inside letter" and to understand the higher level protocols in order to figure where to forward the messages. At the level where these multiplexing techniques reside even IP is a higher level protocol, and so are ST and PUP. We plan that the entire ISI environment would share a single 8-bit address space, spanned by several local networks, Funnels and probably some other packet-multiplexing schemes. This environment, which we like to refer to as a "site", would have connections to several IP-Networks (capital N!). The preferred mode of operation is to use some direct packet multiplexing schemes to deliver the packets directly to their destinations, each of which is capable to perform all the IP-processing. The exception would be to route packet through an explicit Gateway, and even this may be used only for part of the traffic, like for outgoing packets which require routing decisions but not for incoming ones. 5 According to our philosophy the choice for our site between using centralized site gateway and a "distributed-gateway" is our business, and no one else's. A distributed gateway is a scheme where each host performs all the necessary IP-level functions. Note that even the existence of a centralized gateway does not alleviate the need for the distributed one, because every terminal-host must be able to understand IP, unless it has a surrogate which performs this task for it. We happen to believe that other sites with a large number of hosts would like to implement similar schemes which support high efficiency of packet forwarding mechanisms. A concluding comment -------------------- The notion which is advocated in this note is by no mean new. We have learned long ago that any level of protocol should always contain multiplexing information for the next level. In the few instances where this is not done - a price is paid for this error. For example, the good old LINKs (or Message-ID's) used to play such a role, and so do NCP-SOCKETs and TCP-PORTs. -------