As per Relevance of the word datagram, we have this rfc below:
RFC: 814
NAME, ADDRESSES, PORTS, AND
David D.
MIT Laboratory for Computer
Computer Systems and Communications
July, 1982
1.
It has been said that the principal function of an operating
is to define a number of different names for the same object, so that
can busy itself keeping track of the relationship between all of
different names. Network protocols seem to have somewhat the
characteristic. In TCP/IP, there are several ways of referring
things. At the human visible interface, there are character
"names" to identify networks, hosts, and services. Host names
translated into network "addresses", 32-bit values that identify
network to which a host is attached, and the location of the host
that net. Service names are translated into a "port identifier",
in TCP is a 16-bit value. Finally, addresses are translated
"routes", which are the sequence of steps a packet must take to
the specified addresses. Routes show up explicitly in the form of
internet routing options, and also implicitly in the address to
translation tables which all hosts and gateways maintain
This RFC gives suggestions and guidance for the design of
tables and algorithms necessary to keep track of these various sorts
identifiers inside a host implementation of TCP/IP
2
2. The Scope of the
One of the first questions one can ask about a naming mechanism
how many names one can expect to encounter. In order to answer this,
is necessary to know something about the expected maximum size of
internet. Currently, the internet is fairly small. It contains no
than 25 active networks, and no more than a few hundred hosts.
makes it possible to install tables which exhaustively list all of
elements. However, any implementation undertaken now should be based
an assumption of a much larger internet. The guidelines
recommended are an upper limit of about 1,000 networks. If we
an average number of 25 hosts per net, this would suggest a
number of 25,000 hosts. It is quite unclear whether this host
is high or low, but even if it is off by several factors of two,
resulting number is still large enough to suggest that current
management strategies are unacceptable. Some fresh techniques will
required to deal with the internet of the future
3.
As the previous section suggests, the internet will eventually
a sufficient number of names that a host cannot have a static
which provides a translation from every name to its associated address
There are several reasons other than sheer size why a host would
wish to have such a table. First, with that many names, we can
names to be added and deleted at such a rate that an installer
spend all his time just revising the table. Second, most of the
will refer to addresses of machines with which nothing will ever
3
exchanged. In fact, there may be whole networks with which a
host will never have any traffic
To cope with this large and somewhat dynamic environment,
internet is moving from its current position in which a single
table is maintained by the NIC and distributed to all hosts, to
distributed approach in which each network (or group of networks)
responsible for maintaining its own names and providing a "name server
to translate between the names and the addresses in that network.
host is assumed to store not a complete set of name-
translations, but only a cache of recently used names. When a name
provided by a user for translation to an address, the host will
examine its local cache, and if the name is not found there,
communicate with an appropriate name server to obtain the information
which it may then insert into its cache for future reference
Unfortunately, the name server mechanism is not totally in place
the internet yet, so for the moment, it is necessary to continue to
the old strategy of maintaining a complete table of all names in
host. Implementors, however, should structure this table in such a
that it is easy to convert later to a name server approach.
particular, a reasonable programming strategy would be to make the
table accessible only through a subroutine interface, rather than
scattering direct references to the table all through the code. In
way, it will be possible, at a later date, to replace the
with one capable of making calls on remote name servers
A problem which occasionally arises in the ARPANET today is
4
the information in a local host table is out of date, because a host
moved, and a revision of the host table has not yet been installed
the NIC. In this case, one attempts to connect to a particular host
discovers an unexpected machine at the address obtained from the
table. If a human is directly observing the connection attempt,
error is usually detected immediately. However, for
operations such as the sending of queued mail, this sort of problem
lead to a great deal of confusion
The nameserver scheme will only make this problem worse, if
cache locally the address associated with names that have been
up, because the host has no way of knowing when the address has
and the cache entry should be removed. To solve this problem, plans
currently under way to define a simple facility by which a host
query a foreign address to determine what name is actually
with it. SMTP already defines a verification technique based on
approach
4.
The IP layer must know something about addresses. In particular
when a datagram is being sent out from a host, the IP layer must
where to send it on the immediately connected network, based on
internet address. Mechanically, the IP first tests the internet
to see whether the network number of the recipient is the same as
network number of the sender. If so, the packet can be sent directly
the final recipient. If not, the datagram must be sent to a gateway
further forwarding. In this latter case, a second decision must
5
made, as there may be more than one gateway available on the
attached network
When the internet address format was first specified, 8 bits
reserved to identify the network. Early implementations
implemented the above algorithm by means of a table with 256 entries
one for each possible net, that specified the gateway of choice for
net, with a special case entry for those nets to which the host
immediately connected. Such tables were sometimes statically filled in
which caused confusion and malfunctions when gateways and networks
(or crashed).
The current definition of the internet address provides
different options for network numbering, with the goal of allowing
very large number of networks to be part of the internet. Thus, it
no longer possible to imagine having an exhaustive table to select
gateway for any foreign net. Again, current implementations must use
strategy based on a local cache of routing information for
currently being used
The recommended strategy for address to route translation is
follows. When the IP layer receives an outbound datagram
transmission, it extracts the network number from the
address, and queries its local table to determine whether it knows
suitable gateway to which to send the datagram. If it does, the job
done. (But see RFC 816 on Fault Isolation and Recovery,
recommendations on how to deal with the possible failure of
gateway.) If there is no such entry in the local table, then select
6
accessible gateway at random, insert that as an entry in the table,
use it to send the packet. Either the guess will be right or wrong.
it is wrong, the gateway to which the packet was sent will return
ICMP redirect message to report that there is a better gateway to
the net in question. The arrival of this redirect should cause
update of the local table
The number of entries in the local table should be determined
the maximum number of active connections which this particular host
support at any one time. For a large time sharing system, one
imagine a table with 100 or more entries. For a personal computer
used to support a single user telnet connection, only one address
gateway association need be maintained at once
The above strategy actually does not completely solve the problem
but only pushes it down one level, where the problem then arises of
a new host, freshly arriving on the internet, finds all of
accessible gateways. Intentionally, this problem is not solved
the internetwork architecture. The reason is that different
have drastically different strategies for allowing a host to find
about other hosts on its immediate network. Some nets permit
broadcast mechanism. In this case, a host can send out a message
expect an answer back from all of the attached gateways. In
cases, where a particular network is richly provided with tools
support the internet, there may be a special network mechanism which
host can invoke to determine where the gateways are. In other cases,
may be necessary for an installer to manually provide the name of
7
least one accessible gateway. Once a host has discovered the name
one gateway, it can build up a table of all other available gateways,
keeping track of every gateway that has been reported back to it in
ICMP message
5. Advanced Topics in Addressing and
The preceding discussion describes the mechanism required in
minimal implementation, an implementation intended only to
operational service access today to the various networks that make
the internet. For any host which will participate in future research
as contrasted with service, some additional features are required
These features will also be helpful for service hosts if they wish
obtain access to some of the more exotic networks which will become
of the internet over the next few years. All implementors are urged
at least provide a structure into which these features could be
integrated
There are several features, either already a part of
architecture or now under development, which are used to modify
expand the relationships between addresses and routes. The IP
route options allow a host to explicitly direct a datagram through
series of gateways to its foreign host. An alternative form of the
redirect packet has been proposed, which would return
specific to a particular destination host, not a destination net
Finally, additional IP options have been proposed to identify
routes within the internet that are unacceptable. The difficulty
implementing these new features is that the mechanisms do not
8
entirely within the bounds of IP. All the mechanisms above are
to apply to a particular connection, so that their use must be
at the TCP level. Thus, the interface between IP and the layers
it must include mechanisms to allow passing this information back
forth, and TCP (or any other protocol at this level, such as UDP),
be prepared to store this information. The passing of
between IP and TCP is made more complicated by the fact that some of
information, in particular ICMP packets, may arrive at any time.
normal interface envisioned between TCP and IP is one across
packets can be sent or received. The existence of asynchronous
messages implies that there must be an additional channel between
two, unrelated to the actual sending and receiving of data. (In fact
there are many other ICMP messages which arrive asynchronously and
must be passed from IP up to higher layers. See RFC 816,
Isolation and Recovery.)
Source routes are already in use in the internet, and
implementations will wish to be able to take advantage of them.
following sorts of usages should be permitted. First, a user,
initiating a TCP connection, should be able to hand a source route
TCP, which in turn must hand the source route to IP with every
datagram. The user might initially obtain the source route by
a different sort of name server, which would return a source
instead of an address, or the user may have fabricated the source
manually. A TCP which is listening for a connection, rather
attempting to open one, must be prepared to receive a datagram
contains a IP return route, in which case it must remember this
route, and use it as a source route on all returning datagrams
9
6. Ports and Service
The IP layer of the architecture contains the address
which specifies the destination host to which the datagram is
sent. In fact, datagrams are not intended just for particular hosts
but for particular agents within a host, processes or other
that are the actual source and sink of the data. IP performs only
very simple dispatching once the datagram has arrived at the
host, it dispatches it to a particular protocol. It is
responsibility of that protocol handler, for example TCP, to
dispatching the datagram to the particular connection for which it
destined. This next layer of dispatching is done using "
identifiers", which are a part of the header of the higher
protocol, and not the IP layer
This two-layer dispatching architecture has caused a problem
certain implementations. In particular, some implementations
wished to put the IP layer within the kernel of the operating system
and the TCP layer as a user domain application program.
adherence to this partitioning can lead to grave performance problems
for the datagram must first be dispatched from the kernel to a
process, which then dispatches the datagram to its final
process. The overhead of scheduling this dispatch process can
limit the achievable throughput of the implementation
As is discussed in RFC 817, Modularity and Efficiency in
Implementations, this particular separation between kernel and
leads to other performance problems, even ignoring the issue of
10
level dispatching. However, there is an acceptable shortcut which
be taken to move the higher level dispatching function into the
layer, if this makes the implementation substantially easier
In principle, every higher level protocol could have a
dispatching algorithm. The reason for this is discussed below
However, for the protocols involved in the service offering
implemented today, TCP and UDP, the dispatching algorithm is exactly
same, and the port field is located in precisely the same place in
header. Therefore, unless one is interested in participating in
protocol research, there is only one higher level dispatch algorithm
This algorithm takes into account the internet level foreign address
the protocol number, and the local port and foreign port from the
level protocol header. This algorithm can be implemented as a sort
adjunct to the IP layer implementation, as long as no other higher
protocols are to be implemented. (Actually, the above statement is
partially true, in that the UDP dispatch function is subset of the
dispatch function. UDP dispatch depends only protocol number and
port. However, there is an occasion within TCP when this exact
subset comes into play, when a process wishes to listen for a
from any foreign host. Thus, the range of mechanisms necessary
support TCP dispatch are also sufficient to support precisely the
requirement.)
The decision to remove port level dispatching from IP to the
level protocol has been questioned by some implementors. It has
argued that if all of the address structure were part of the IP layer
11
then IP could do all of the packet dispatching function within the host
which would lead to a simpler modularity. Three problems
identified with this. First, not all protocol implementors could
on the size of the port identifier. TCP selected a fairly short
identifier, 16 bits, to reduce header size. Other protocols
designed, however, wanted a larger port identifier, perhaps 32 bits,
that the port identifier, if properly selected, could be
probabilistically unique. Thus, constraining the port id to
particular IP level mechanism would prevent certain fruitful lines
research. Second, ports serve a special function in addition
datagram delivery: certain port numbers are reserved to
particular services. Thus, TCP port 23 is the remote login service.
ports were implemented at the IP level, then the assignment of
known ports could not be done on a protocol basis, but would have to
done in a centralized manner for all of the IP architecture. Third,
was designed with a very simple layering role: IP contained
those functions that the gateways must understand. If the port idea
been made a part of the IP layer, it would have suggested that
needed to know about ports, which is not the case
There are, of course, other ways to avoid these problems.
particular, the "well-known port" problem can be solved by devising
second mechanism, distinct from port dispatching, to name well-
ports. Several protocols have settled on the idea of including, in
packet which sets up a connection to a particular service, a
general service descriptor, such as a character string field.
special packets, which are requesting connection to a
12
service, are routed on arrival to a special server, sometimes called
"rendezvous server", which examines the service request, selects
random port which is to be used for this instance of the service,
then passes the packet along to the service itself to commence
interaction
For the internet architecture, this strategy had the serious
that it presumed all protocols would fit into the same service paradigm
an initial setup phase, which might contain a certain overhead such
indirect routing through a rendezvous server, followed by the packets
the interaction itself, which would flow directly to the
providing the service. Unfortunately, not all high level protocols
internet were expected to fit this model. The best example of this
isolated datagram exchange using UDP. The simplest exchange in UDP
one process sending a single datagram to another. Especially on a
net, where the net related overhead is very low, this kind of
single datagram interchange can be extremely efficient, with very
overhead in the hosts. However, since these individual packets
not be part of an established connection, if IP supported a
based on a rendezvous server and service descriptors, every
datagram would have to be routed indirectly in the receiving
through the rendezvous server, which would substantially increase
overhead of processing, and every datagram would have to carry the
service request field, which would increase the size of the
header
In general, if a network is intended for "virtual circuit service",
13
or things similar to that, then using a special high overhead
for circuit setup makes sense. However, current directions in
are leading away from this class of protocol, so once again
architecture was designed not to preclude alternative
structures. The only rational position was that the
dispatching strategy used should be part of the higher level
design, not the IP layer
This same argument about circuit setup mechanisms also applies
the design of the IP address structure. Many protocols do not
a full address field as part of every packet, but rather transmit
short identifier which is created as part of a circuit setup from
to destination. If the full address needs to be carried in only
first packet of a long exchange, then the overhead of carrying a
long address field can easily be justified. Under these circumstances
one can create truly extravagant address fields, which are capable
extending to address almost any conceivable entity. However,
strategy is useable only in a virtual circuit net, where the
being transmitted are part of a established sequence, otherwise
large extravagant address must be transported on every packet.
Internet explicitly rejected this restriction on the architecture,
was necessary to come up with an address field that was compact
to be sent in every datagram, but general enough to correctly route
datagram through the catanet without a previous setup phase. The
address of 32 bits is the compromise that results. Clearly it
a substantial amount of shoehorning to address all of the
places in the universe with only 32 bits. On the other hand, had
14
address field become much bigger, IP would have been susceptible
another criticism, which is that the header had grown unworkably large
Again, the fundamental design decision was that the protocol be
in such a way that it supported research in new and different sorts
protocol architectures
There are some limited restrictions imposed by the IP design on
port mechanism selected by the higher level process. In particular
when a packet goes awry somewhere on the internet, the offending
is returned, along with an error indication, as part of an ICMP packet
An ICMP packet returns only the IP layer, and the next 64 bits of
original datagram. Thus, any higher level protocol which wishes to
out from which port a particular offending datagram came must make
that the port information is contained within the first 64 bits of
next level header. This also means, in most cases, that it is
to imagine, as part of the IP layer, a port dispatch mechanism
works by masking and matching on the first 64 bits of the
higher level header
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
