RFC relevance of contains

As per Relevance of the word contains, we have this rfc below:

Network Working Group D.L.
Request for Comments: 891 December 1983

DCN Local-Network

This RFC is a description of the protocol used in the DCN
networks to maintain connectivity, routing, and
information. These procedures may be of interest to designers
implementers of other networks

1.

This document describes the local-net architecture and
of the Distributed Computer Network (DCN), a family of local
based on Internet technology and an implementation of PDP11-
software called the Fuzzball. DCN local nets have been in
for about three years and now include clones in the USA, UK,
and West Germany. They typically include a number of PDP11 or LSI-11
Fuzzballs, one of which is elected a gateway, and often include
Internet-compatible hosts as well

The DCN local-net protocols are intended to provide connectivity
routing and timekeeping functions for a set of randomly
personal computers and service hosts. The design philosophy
the Fuzzball implementation is to incorporate complete
in every host, which can serve as a packet switch, gateway and
host all at the same time. When a set of Fuzzballs are
together using a haphazard collection of serial, parallel
contention-bus interfaces, they organize themselves into a
with routing based on minimum delay

The purpose of this document is to describe the local-
protocols used by the DCN to maintain connectivity, routing
timekeeping functions. The document is an extensive revision
expansion of Section 4.2 of [1] and is divided into two parts,
first of which is an informal description of the architecture
together with explanatory remarks. The second part consists of
semi-formal specification of the entities and protocols used
determine connectivity, establish routing and maintain
synchronization and is designed to aid in the implementation of
systems. The link-level coding is described in the appendix

2. Narrative

The DCN architecture is designed for local nets of up to 256
hosts and gateways using the Internet Protocol (IP) and
protocols. It provides adaptive routing and clock
functions in an arbitrary topology including point-to-point links
multipoint bus systems. It is intended for use in connecting
computers to each other and to service machines, gateways and
hosts of the Internet community. However, it is not intended for
in large, complex networks and does not support the
routing and control algorithms of, for example, the ARPANET

A brief description of the process and addressing structure
in the DCN may be useful in the following. A DCN physical host is
PDP11-compatible processor which supports a number of
sequential processes, each

DCN Local-Network Protocols Page 2
D.L.

which is given a unique 8-bit identifier called its port ID.
DCN physical host contains one or more internet processes, each
which supports a virtual host given a unique 8-bit identifier
its host ID

Each virtual host can support multiple internet protocols
connections and, in addition, a virtual clock. Each physical
contains a physical clock which can operate at an arbitrary rate and
in addition, a 32-bit logical clock which operates at 1000 Hz and
assumed to be reset each day at 0000 hours UT. Not all physical
implement the full 32-bit precision; however, in such cases
resolution of the logical clock may be somewhat less

There is a one-to-one correspondence between Internet
and host IDs. The host ID is formed from a specified octet of
Internet address to which is added a specified offset. The
number and offset are selected at configuration time and must be
same for all DCN hosts sharing the local net. For class-B and class-
nets normally the fourth octet is used in this way for routing
the local net. In the case of class-B nets, the third octet
considered part of the net number by DCN hosts; therefore, this
can be used for routing between DCN local nets. For class-A
normally the third octet (ARPANET logical-host field) is used
routing where necessary

Each DCN physical host is identified by a host ID for the
of detecting loops in routing updates, which establish
minimum-delay paths between the virtual hosts. By convention,
physical host ID is assigned as the host ID of one of its
hosts. A link to a neighbor net is associated with a special
host, called a gateway, which is assigned a unique host ID

The links connecting the various physical hosts together and
foreign nets can be distributed in arbitrary ways, so long as the
remains fully connected. If full connectivity is lost, due to a
or host fault, the virtual hosts in each of the surviving segments
continue to operate with each other and, once connectivity
restored, with all of them

Datagram routing is determined entirely by internet address -
there is no local leader as in the ARPANET. Each physical
contains two tables, the Host Table, which is used to determine
outgoing link to each other local-net host, and the Net Table,
is used to determine the outgoing host (gateway) to each other net
The Host Table contains estimates of roundtrip delay and logical-
offset for all virtual hosts in the net and is indexed by host ID
For the purpose of computing these estimates the delay and offset
each virtual host relative to the physical host in which it resides
assumed zero. The single exception to this is a special virtual
associated with an NBS radio time-code receiver, where the offset
computed relative to the broadcast time

The Net Table contains an entry for every neighbor net that
be connected to the local net and, in addition, certain other
that are

DCN Local-Network Protocols Page 3
D.L.

neighbors. Each entry contains the net number, as well as the host
of the local-net gateway to that net. The routing function
looks up the net number in the Net Table, finds the host ID of
gateway and retrieves the port ID of the net-output process from
Host Table. Other information is included in the Host Table and
Table as described below

The delay and offset estimates are updated by HELLO
exchanged on the links connecting physical-host neighbors. The
messages are exchanged frequently, but not so as to materially
the throughput of the link for ordinary data messages. A
message contains a copy of the delay and offset information from
Host Table of the sender, as well as information to compute
roundtrip delay and logical-clock offset of the receiver relative
the sender

The routing algorithm is similar to that (formerly) used in
ARPANET and other places in that the roundtrip (biased) delay
calculated to a neighbor is added to each of the delay estimates
in its HELLO message and compared with the corresponding
estimates in the Host Table. If a delay computed in this way is
than the delay already in the Host Table, the routing to
corresponding virtual host is changed accordingly. The
operation of this algorithm, which includes provisions for
up-down logic and loop suppression, is summarized in a later section

DCN local nets are self-configuring for all hosts and
nets; that is, the routing algorithms will find minimum-delay
between all hosts and gateways to neighbor nets. In addition
timekeeping information can be exchanged using special HELLO
between neighboring DCN local nets. For routing beyond neighbor
additional entries can be configured in the Net Tables as required
In addition, a special entry can be configured in the Net Tables
specifies the host ID of the gateway to all nets not
included in the table

For routing via the ARPANET and its reachable nets a
local-net host is equipped with an IMP interface and configured with
GGP/EGP Gateway process. This process maintains the Net Table of
local host, including ARPANET leaders, dynamically as part of
GGP/EGP protocol interactions with other ARPANET gateways. GGP/
protocol interactions are possibly with non-ARPANET gateways as well

The portable virtual-host structure used in the DCN encourages
rather loose interpretation of addressing. In order to
confusion in the following, the term "host ID" will be applied only
virtual hosts, while "host number" will be applied to the
host, called generically the DCN host

2.1. Net and Host

There are two tables in every DCN host which control routing
Internet Protocol (IP) datagrams: the Net Table and the Host Table
The Net Table is used to determine the host ID of the gateway on
route to a foreign net

DCN Local-Network Protocols Page 4
D.L.

while the Host Table is used to determine the link, with respect
the DCN host, on the route to a virtual host. The Host Table
maintained dynamically using updates generated by periodic
messages. The Net Table is fixed at configuration time for all
hosts except those that support a GGP/EGP Gateway process. In
cases the Net Table is updated as part of the gateway operations.
addition, entries in either table can be changed by operator commands

The Net Table format is shown in Figure 1.

1 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Net(2) | Net(1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Net(3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hops | Gateway ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Leader |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1. Net Table

The "Net Name" field defines a short (RAD50) name for the net
while the "Net" fields define the class A/B/C net number.
"Gateway ID" field contains the host ID of the first gateway to
net and the "Hops" field the number of hops to it. The
fields are used only by the GGP/EGP Gateway process and include
"Index" field, which contains an index into the routing matrix.
the "Gateway Leader" field, which contains the (byte-swapped
local-net leader for the gateway on a neighbor net

The Net Table contains an indefinite number of entries and
terminated by a special entry with all "Net" fields set to zero.
the "Hops" field of this entry is less than 255, the "Gateway ID
field of this entry is used for all nets not in the table. If
"Hops" field is 255 all nets not explicitly mentioned in the
appear unreachable

The Host Table format is shown in Figure 2.

DCN Local-Network Protocols Page 5
D.L.

1 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Local Leader |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Update Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. Host Table

The ordinal position of each Host Table entry corresponds to
host ID. The "Name" field contains a short (RAD50) name
convenient reference. The "Port ID" field contains the port ID of
net-output process on the shortest path to this virtual host and
"Delay" field contains the measured roundtrip delay to it.
"Offset" field contains the difference between the logical clock
this host and the logical clock of the local host. The "Local Leader
field contains information used to construct the local leader of
outgoing packet, for those nets that require it. The "
Timestamp" field contains the logical clock value when the entry
last updated and the "TTL" field the time (in seconds) remaining
the virtual host is declared down

All fields except the "Name" field are filled in as part of
routing update process, which is initiated upon arrival of a
message from a neighboring DCN host. This message takes the form
an IP datagram carrying the reserved protocol number 63 and a
field as shown in Figure 3.

DCN Local-Network Protocols Page 6
D.L.

1 0
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fixed | Checksum |
Area +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Date |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Time +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Hosts (n) |
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host | Delay Host 0 |
Area +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Host 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Host n-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Host n-1 |
--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3. HELLO Message

There are two HELLO message formats, depending on the length
the message. One format, sent by a DCN host to another host on
same local net, includes both the fixed and host areas shown above
The second format, sent in all other cases, includes only the
area

Note that all word fields shown are byte-swapped with respect
the ordinary PDP11 representation. The "Checksum" field contains
checksum covering the fields indicated. The "Date" and "Time"
are filled in with the local date and time of origination.
"Timestamp" field is used in the computation of the roundtrip
(see below). The "Offset" field contains the offset of the block
Internet addresses used by the local net. The "Delay Host n"
"Offset Host n" fields represent a copy of the corresponding
of the Host Table as they exist at the time of origination.
"Hosts (n)" field contains the number of entries in this table

2.2. Roundtrip Delay

Periodically, each DCN physical host sends a HELLO message to
neighbor on each of the communication links common to both of them
For each of these links the sender keeps a set of state variables
including a copy of the source-address field of the last HELLO
received.

DCN Local-Network Protocols Page 7
D.L.

When constructing a HELLO message the sender sets
destination-address field to this state variable and
source-address field to its own address. It then fills in the "Date
and "Time" fields from its logical clock and the "Timestamp"
from another state variable. It finally copies the "Delay"
"Offset" values from its Host Table into the message

A host receiving a HELLO message discards it if the format is
or the checksum fails. If valid, it initializes a link state
to show that the link is up. Each time a HELLO message is
this state variable is decremented. If it decrements to zero the
is declared down

The host then checks if the source-address field matches
state variable containing the last address stored. If not, the
has been switched to a new host, so the state variables are
and the link forced into a recovery state. The host then checks
the destination-address field matches its own address. If so,
message has been looped (legal only in the case of a broadcast net
and the roundtrip delay information is corrected. The host and
areas are ignored in this case. If not, the host and net areas of
message are processed to update the Host and Net Tables

Roundtrip delay calculations are performed in the following way
The link input/output processes assigned each link maintain
internal state variable which is updated as each HELLO message
received and transmitted. When a HELLO message is received
variable takes the value of the "Time" field minus the
time-of-day. When the next HELLO message is transmitted, the
assigned the "Timestamp" field is computed as the low-order 16-bits
this variable plus the current time-of-day. The value of
variable is forced to zero if either the link is down of the
logical clock has been reset since the last HELLO message
received

If a HELLO message is received with zero "Timestamp" field,
processing other than filling in the internal state variable
Otherwise, the roundtrip delay is computed as the low-order 16-bits
the current time-of-day minus the value of this field. In order
assure the highest accuracy, the calculation is performed only if
length of the last transmitted HELLO message (in octets) matches
length of the received HELLO message

The above technique renders the calculation independent of
clock offsets and intervals between HELLO messages at either host
protects against errors that might occur due to lost HELLO
and works even when a neighbor host simply forwards the HELLO
back to the originator without modifying it. The latter behavior
typical of ARPANET IMPs and gateways, as well as broadcast nets,
on the loop-detection mechanism so that correct calculations can
made and, furthermore, that spurious host updates can be avoided

DCN Local-Network Protocols Page 8
D.L.

2.3. Host

When a HELLO message arrives which results in a valid
delay calculation, a host update process is performed. This
of adding the roundtrip delay to each of the "Delay Host n" entries
the HELLO message in turn and comparing each of these
delays to the "Host Delay" field of the corresponding Host
entry. Each entry is then updated according to the following rules

1. If the link connects to another DCN host on the same net and
port ID (PID) of the link output process matches the "Port ID
field of the entry, then update the entry

2. If the link connects to another DCN host on the same net, the
of the link output process does not match the "Port ID" field and
calculated delay is less than the "Host Delay" field by at least
specified switching threshold (currently 100 milliseconds),
update the entry.

3. If the link connects to a foreign net and is assigned a host
corresponding to the entry, then update the entry. In this
only, use as the calculated delay the roundtrip delay

4. If none of the above conditions are met, or if the virtual
has been declared down and the "TTL" field contains a
value, then no update is performed

The update process consists of replacing the "Delay" field
the calculated delay, the "Port ID" field with the PID of the
output process, the "Update Timestamp" field with the current time
day and the "TTL" field by a specified value (currently 120)
seconds. If the calculated delay exceeds a specified maximum
(currently 30 seconds), the virtual host is declared down by
the corresponding "Delay" field to the maximum and the
fields as before. For the purposes of delay calculations values
than a specified minimum (currently 100 milliseconds) are rounded
to that minimum

The "Offset" field is also replaced during the update process
When the HELLO message arrives, The value of the current logical
is subtracted from the "Time" field and the difference added
one-half the roundtrip delay. The resulting sum, which represents
offset of the local clock to the clock of the sender, is added to
corresponding "Offset" field of the HELLO message and the sum
the "Offset" field of the Host Table. Thus, the "Offset" field in
Host Table for a particular virtual host is replaced only if that
is up and on the minimum-delay path to the DCN host

The purpose of the switching threshold in (2) above and
minimum delay specification in the update process is to
unnecessary switching between links and transient loops which
occur due to normal variations in propagation delays. The purpose
the "TTL" field test in (4) above is to ensure consistency by
all paths to a virtual host when that virtual host goes down

DCN Local-Network Protocols Page 9
D.L.

In addition to the updates performed as HELLO messages arrive,
virtual host in a DCN host also performs a periodic update of its
Host Table entry. The update procedure is identical to the above
except that the calculated delay and offset are taken as zero.
least one of the virtual hosts in a DCN host must have the same
ID as the host number assigned the DCN host itself and all must
assigned the same net number. Other than these, there are
restrictions on the number or addresses of internet processes
in a single DCN host

It should be appreciated that virtual hosts are truly
and can migrate about the net, should such a requirement arise.
host update protocols described here insure that the
procedures always converge to the minimum-delay paths via
links and DCN hosts. In the case of broadcast nets such as Ethernets
the procedures are modified slightly as described below. In this
the HELLO messages are used to determine routing from the
Ethernet hosts to destinations off the cable, as well as to
time synchronization

2.4.

The "TTL" field in every Host Table entry is decremented once
second in normal operation. Thus, if following a host update
update is not received within an interval corresponding to the
initialized in that field, it decrements to zero, at which point
virtual host is declared down and the Host Table entry set
described above. The 120-second interval used currently provides
at least four HELLO messages to be generated by every neighbor
every link during that interval, since the maximum delay between
messages is 30 seconds on the lowest-speed link (1200 bps). Thus,
no HELLO messages are lost, the maximum number of links between
virtual host and any other is four

The "TTL" field is initialized at 120 seconds when an
occurs and when the virtual host is declared down. During
interval this field decrements to zero immediately after
declared down, updates are ignored. This provides a decent
for the bad news to propagate throughout the net and for the
Tables in all DCN hosts to reflect the fact. Thus, the formation
routing loops is prevented

The IP datagram forwarding procedures call for decrementing
"time-to-live" field in the IP header once per second or at each
where it is forwarded, whichever comes first. The value
currently for this purpose is 30, so that an IP datagram can live
the net no longer than that number of seconds. This is thus
maximum delay allowed on any path between two virtual hosts. If
maximum delay is exceeded in calculating the roundtrip delay for
Host Table entry, the corresponding virtual host will be
down

DCN Local-Network Protocols Page 10
D.L.

The interval between HELLO messages on any link depends on
data rate supported by the link. As a general rule, this interval
set at 16 times the expected roundtrip time for the longest packet
be sent on that link. For 1200-bps asynchronous transmission
packet lengths to 256 octets, this corresponds to a maximum
message interval of about 30 seconds.

Although the roundtrip delay calculation, upon which the
process depends, is relatively insensitive to net traffic
congestion, stochastic variations in the calculated values
occur due to coding (bit or character stuffing) and
perturbations. In order to suppress loops and needless path changes
minimum switching threshold is incorporated into the routing
(see above). The interval used for this threshold, as well as for
minimum delay on any path, is 100 milliseconds

3. Formal

The following sections provide a formal framework which
the DCN HELLO protocol. This protocol is run between neighboring
hosts that share a common point-to-point link and provides
connectivity determination, routing and timekeeping functions

The descriptions to follow are organized as follows: First
summary of data structures describes the global variables and
formats. Then three processes which implement the protocol
described: the CLOCK, HELLO and HOST processes. The description
these processes is organized into sections that describe (1) the
variables used by that process, (2) the parameters and constants
(3) the events that initiate processing together with the
they evoke. In the case of variables a distinction is made
state variables, which retain their contents between procedure calls
and temporaries, which have a lifetime extending only while
process is running. Except as noted below, the initial contents
state variables are unimportant

3.1. Data

3.1.1. Global

This is a 32-bit bit-string temporary variable used to contain
Internet address

CLOCK-
This is an eight-bit integer state variable used to contain
host ID of the local-net host to be used as the master clock.
is initialized to the appropriate value depending upon the
configuration.

This is a 16-bit bit-string state variable used to contain
date in RT-11 format. Bits 0-4 contain the year, with
corresponding to 1972, bits 5-9 contain the day of the month

DCN Local-Network Protocols Page 11
D.L.

bits 10-14 contain the month, starting with one for January

DATE-
This is a one-bit state variable used to indicate whether
local date and time are synchronized with the master clock.
value of one indicates the local clock is not synchronized
the master clock. This variable is set to one initially and
the local time-of-day rolls over past midnight. It is set to
each time a valid date and time update has been received from
master clock.

This is a 16-bit integer temporary variable which represents
roundtrip delay in milliseconds to a host

This is an eight-bit integer temporary variable containing
host ID of some host on the local net

There is a one-to-one correspondence between the
addresses of local hosts and their HIDs. The mapping between
is selected on the basis of the octet number of the
address. For DCN hosts it is the fourth octet, while for
directly connected to a class-A ARPANET IMP or gateway, it is
third octet (logical-host field). The contents of this octet
to be added to ADDRESS-OFFSET to form the HID associated
with the address

This is an eight-bit counter state variable indicating
timestamps are valid or not. While HOLD is nonzero,
should be considered invalid. When set to some nonzero value,
counter decrements to zero at a 1-Hz rate. Its initial value
zero.

HOST-
This is a table of NHOSTS entries indexed by host ID (HID).
is one entry for each host in the local net. Each entry has
following format

HOST-TABLE.
This is a 16-bit field containing the computed roundtrip
in milliseconds to host HID

HOST-TABLE.
This is a 16-bit field containing the computed signed
in milliseconds which must be added to the local
clock to agree with the apparent clock of host HID

HOST-TABLE.
This is an eight-bit field containing the PID of the net-
process selected by the routing algorithm to forward
to host HID

DCN Local-Network Protocols Page 12
D.L.

HOST-TABLE.
This is an eight-bit field used as a time-to-live indicator
It is decremented by the HOST process once each second
initialized to a chosen value when a HELLO message
received. The table is initialized with the HOST-TABLE.
field set to MAXDELAY for all entries. The contents of
other fields are unimportant.

LOCAL-
This is a 32-bit bit-string state variable used to contain the
local host Internet address

NET-
This is a table of NNETS entries with the following format

NET-TABLE.
This is an eight-bit field containing the host ID of
pseudo-process to forward packets to the NET-TABLE.NET net

NET-TABLE.
This is a 24-bit field containing an Internet class-A (
bits), class-B (16 bits) or class-C (24 bits) net number
Note that the actual field width for class-B net numbers is 24
bits in order to provide a subnet capability, in which
high-order eight bits of the 16-bit host address
interpreted as the subnet number.

The table is constructed at configuration time and must include
entry for every net that is a potential neighbor. A neighbor
is defined as a net containing a host that can be
connected to a host on the local net. The entry for such a net
initialized with NET-TABLE.NET set to the neighbor net number
NET-TABLE.HID set to an arbitrary vitual-host ID not assigned
other local-net virtual host.

The remaining entries in NET-TABLE are initialized at initial-
time with the NET-TABLE.NET fields set to zero and
NET-TABLE.HID fields set to a configuration-selected host ID to
used to forward packets to all nets other than neighbor nets.
the case where a gateway module is included in the local
configuration, the GGP and/or EGP protocols will be used
maintain these entries; while, in the case where no
module is included, only one such entry is required.

This is a 16-bit signed integer temporary variable
represents the offset in milliseconds to be added to the
clock time to yield the apparent clock time of the neighbor host.

3.1.2.

ADDRESS-
This is an integer which represents the value of the Internet
address field corresponding to the first host in HOST-TABLE

DCN Local-Network Protocols Page 13
D.L.

This is an integer which defines the number of entries in HOST-TABLE

This is an integer which defines the number of entries in MET-TABLE

3.1.3. HELLO Packet

PKT.ADDRESS-
This eight-bit is copied from ADDRESS-OFFSET by the sender

PKT.
Bits 0-14 of this 16-bit field are copied from DATE by the sender,
while bit 15 is copied from DATE-VALID

PKT.DATE-
This one-bit field is bit 15 of PKT.DATESTAMP

PKT.
This 32-bit field is part of the IP header. It is copied
HLO.NEIGHBOR-ADDRESS by the sender

PKT.HOST-
This is a table of PKT.NHOSTS entries, each entry of
consists of two fields. The entries are indexed by host ID
have the following format:

PKT.HOST-TABLE.
This 16-bit field is copied from the corresponding HOST-TABLE.
field by the sender

PKT.HOST-TABLE.
This 16-bit field is copied from the corresponding HOST-TABLE.
field by the sender

PKT.
This 16-bit field is part of the IP header. It is set by the sender
the number of octets in the packet

PKT.
This eight-bit field is copied from NHOST by the sender

PKT.
This 16-bit field is part of the IP header. It is copied
LOCAL-ADDRESS by the sender

PKT.
This 32-bit field contains the apparent time the packet was transmitted
in milliseconds past midnight UT

DCN Local-Network Protocols Page 14
D.L.

PKT.
This 16-bit field contains a variable used in roundtrip
calculations

3.2 CLOCK Process (CLK

The timekeeping system maintains three clocks: (1) the
clock, which is determined by a hardware oscillator/counter; (2)
apparent clock, which maintains the time-of-day used by
processes and (3) the actual clock, which represents the time-of-
provided by an outside reference. The apparent and actual clocks
maintained as 48-bit quantities with 32 bits of significance
to client processes. These clocks run at a rate of 1000 Hz and
reset at midnight UT

The CLOCK process consists of a set of state variables along
a set of procedures that are called as the result of
interrupts and client requests. An interval timer is
logically separate from the local clock mechanism, although both
be derived from the same timing source

3.2.1. Local

CLK.
This is a 48-bit fixed-point state variable used to represent
apparent time-of-day. The decimal point is to the right of bit 16
(numbering from the right at bit 0). Bit 16 increments at a
equivalent to 1000 Hz independent of the hardware clock. (In
case of programmable-clock hardware the value of CLK.CLOCK must
corrected as described below.)

CLK.
This is a hardware register that increments at rate R. It can
represented by a simple line clock, which causes interrupts at
line-frequency rate, or by a programmable clock, which contains a 16-
register that is programmed to count at a 1000-Hz rate and causes
interrupt on overflow. The register is considered a fixed-point
with decimal point to the right of bit 0.

CLK.
This is a 48-bit signed fixed-point state variable used to represent
increment to be added to CLK.CLOCK to yield the actual time-of-day.
decimal point is to the right of bit 16.

3.2.3.

ADJUST-
This is an integer which defines the shift count used to compute
fraction that is used as a multiplier of CLK.DELTA to correct CLK.
once each clock-adjust interval. A value of seven is suggested

DCN Local-Network Protocols Page 15
D.L.

ADJUST-
This is an integer which defines the clock-adjust interval
milliseconds. A value of 500 (one-half second) is suggested
the line clock and 4000 (four seconds) for the 1000-Hz clock

CLOCK-
This is a fixed-point integer which defines the increment
milliseconds to be added to CLK.CLOCK as the result of a
tick. The decimal point is to the right of bit 16. In the
of a line-clock interrupt, the value of CLOCK-TICK should
16.66666 (60 Hz) or 20.00000 (50 Hz). In the case of a 1000-
programmable-clock overflow, the value should be 65536.00000.

HOLD-
This is an integer which defines the number of seconds that HOLD
count down after CLK.CLOCK has been reset. The resulting interval must
at least as long as the maximum HELLO-INTERVAL used by any HELLO process

3.2.3. Events and

INCREMENT-CLOCK
This event is evoked as the result of a tick interrupt, in the case of
line clock, or a counter overflow, in the case of the 1000-Hz clock.
causes the logical clock to be incremented by the value of CLOCK-TICK

1. Add the value of CLOCK-TICK to CLK.CLOCK

ADJUST-CLOCK
This event is evoked once every ADJUST-INTERVAL milliseconds to slew
apparent clock time to the actual clock time as set by the SET-
procedure. This is done by subtracting a fraction of the
factor CLK.DELTA from the value of CLK.DELTA and adding the same
to CLK.CLOCK. This continues until either the next SET-CLOCK call
CLK.DELTA has been reduced to zero

The suggested values for ADJUST-INTERVAL and ADJUST-
represent a maximum slew rate of less than +-2 milliseconds
second, in the case of 1000-Hz clock. The action is to
noisy clock corrections received from neighboring systems
obtain a high-quality local reference, while insuring the
clock time is always monotonically increasing.

1. Shift the 48-bit value of CLK.DELTA arithmetically ADJUST-
bits to the right, discarding bits from the right and saving
result in a temporary variable F. Assuming the decimal point of F
be positioned to the right of bit 16 and sign-extending as necessary
subtract F from CLK.DELTA and add F to CLK.CLOCK

DCN Local-Network Protocols Page 16
D.L.

DECREMENT-HOLD
This event is evoked once per second to decrement the value of HOLD

1. If the value of HOLD is zero, do nothing; otherwise, decrement
value

READ-CLOCK

This procedure is called by a client process. It returns the
time-of-day computed as the integer part of the sum CLK.CLOCK
CLK.COUNT. Note that the precision of the value returned is limited
+-1 millisecond, so that client processes must expect the
time to "run backward" occasionally due to drift corrections.
this happens the backward step will never be greater than
millisecond and will never occur more often than twice per second

1. In the case of line clocks CLK.COUNT is always zero, while
the case of programmable clocks the hardware must
interrogated to extract the value of CLK.COUNT. If
interrogation a counter-overflow condition is evident,
CLOCK-TICK to CLK.CLOCK and interrogate the hardware again

2. When the value of CLK.COUNT has been determined compute the
CLK.COUNT + CLK.CLOCK. If this sum exceeds the number
milliseconds in 24 hours (86,400,000), reduce CLK.CLOCK
86,400,000, set HOLD-INTERVAL -> HOLD, set CLOCK-VALID (bit 15
of DATE) to one, roll over DATE to the next calendar day
start over. If not, return the integer part of the sum as
apparent time-of-day.

The CLOCK-VALID bit is set to insure that a master-clock update
received at least once per day. Note that, in the case
uncompensated crystal oscillators of the type commonly used as
1000-Hz time base, a drift of several parts per million can
expected, which would result in a time drift of several tenths of
second per day, if not corrected

SET-CLOCK
This procedure is called by a client process. It sets a time-of-
correction factor in milliseconds. The argument represents a 32-
signed fixed-point quantity with decimal point to the right of
0 that is to be added to CLK.CLOCK so that READ-CLOCK
returns the actual time-of-day.

1. If the correction factor is in the range -2**(16-ADJUST-FRACTION)
+2**(16-ADJUST-FRACTION) - 1 (about +-128 milliseconds with
suggested value of ADJUST-FRACTION), the value of the
replaces CLK.DELTA and the procedure is complete. If not, add
value of the sign-extended argument to CLK.CLOCK and set CLK.DELTA
zero. In addition, set HOLD-INTERVAL -> HOLD, since
represents a relatively large step-change in apparent time
The value of HOLD represents the remaining number of
in which timestamps should be considered invalid and is
by the HELLO process to suppress roundtrip delay
which might involve invalid timestamps.

DCN Local-Network Protocols Page 17
D.L.

3.3. HELLO

The HELLO process maintains clock synchronization with a
HELLO process using the HELLO protocol. It also participates in
routing algorithm. There is one HELLO process and one set of
state variables for each link connecting the host to one of
neighbors

3.3.1. Local

HLO.
This is a one-bit switch state variable. When set to zero
point-to-point link is assumed. When set to one a broadcast (e.g
Ethernet) link is assumed

HLO.KEEP-
This is an eight-bit counter state variable used to indicate whether
link is up. It is initialized with a value of zero

HLO.
This is a 16-bit integer state variable used to record the length
octets of the last HELLO message sent

HLO.NEIGHBOR-
This is a 32-bit integer state variable used to contain the neighbor
Internet address

HLO.
This is an eight-bit integer state variable used to identify
net-output process associated with this HELLO process. It is
by the kernel when the process is created and remains
thereafter

HLO.
This is a one-bit switch state variable. When set the HELLO
spontaneously sends HELLO messages. When not set the HELLO
responds to HELLO messages, but does not send them spontaneously

HLO.
This is a 32-bit integer temporary variable used to record the time
arrival of a HELLO message

HLO.
This is a 16-bit signed integer state variable used in roundtrip
calculations

DCN Local-Network Protocols Page 18
D.L.

3.3.2.

HELLO-
This is an integer which defines the interval in seconds between
messages. It ranges from about eight to a maximum of 30 seconds
depending on line speed

HOLD-DOWN-
This is an integer which defines the interval in seconds a host will
considered up following receipt of a HELLO message indicating
host is up. A value of 120 is suggested

KEEP-ALIVE-
This is an integer which defines the interval, in units
HELLO-INTERVAL, that a HELLO process will consider the link up.
value of four is suggested

This is an integer which defines the maximum roundtrip delay
seconds on a path to any reachable host. A value of 30 is suggested

This is an integer which defines the minimum switching threshold
milliseconds below which routes will not be changed. A value of 100
suggested

3.3.3. Events and

INPUT-PACKET
When a packet arrives the net-input process first sets HLO.TIMESTAMP
the value returned by the READ-CLOCK procedure, then checks
packet for valid local leader, IP header format and checksum.
the protocol field in the IP header indicates a HELLO message,
packet is passed to the HELLO process. If any errors are
the packet is dropped.

The HELLO process first checks the packet for valid HELLO header
and checksum. If any errors are found the packet is dropped. Otherwise
it proceeds as follows

1. If PKT.SOURCE is equal to LOCAL-ADDRESS, then the line to
neighbor host is looped. If this is a broadcast
(HLO.BROADCAST is set to one), then ignore this nicety;
not, this is considered an error and further processing
abandoned. Note that, in special configurations
other systems (e.g. ARPANET IMPs and gateways) it may
useful to use looped HELLO to monitor connectivity. The
implementation provides this feature, but is not described here

2. Set KEEP-ALIVE-INTERVAL -> HLO.KEEP-ALIVE. This indicates
maximum number of HELLO intervals the HLO.TSP field
considered valid.

DCN Local-Network Protocols Page 19
D.L.

3. Set PKT.TIMESTAMP - HLO.TIMESTAMP -> HLO.TSP. This is part of
roundtrip delay calculation. The value of HLO.TSP will
updated and returned to the neighbor in the next HELLO
transmitted. Next, compute the raw roundtrip delay and offset
HLO.TIMESTAMP - PKT.TSP -> DELAY and HLO.TSP + DELAY/2 -> OFFSET.
Note: in the case of a broadcast link (HLO.BROADCAST set to one)
DELAY to zero

4. Perform this step only in the case of non-broadcast
(HLO.BROADCAST set to zero). If PKT.SOURCE is not equal
HLO.NEIGHBOR-ADDRESS, then a new neighbor has appeared on
link. Set PKT.SOURCE -> HLO.NEIGHBOR ADDRESS, MAXDELAY ->
DELAY and proceed to the next step. This will force the
to be declared down and result in a hold-down cycle
Otherwise, if either PKT.TSP is zero or HOLD is nonzero,
the DELAY calculation is invalid and further processing
abandoned. Note that a hold-down cycle is forced in any
case if a new neighbor is recognized

5. If processing reaches this point the DELAY and
variables can be assumed valid as well as the remaining
in the packet. First, if DELAY < MINDELAY, set MINDELAY ->
DELAY. This avoids needless path switching when
difference in delays is not significant and has the
that on low-delay links the routing algorithm degenerates to
min-hop rather than min-delay. Then set HLO.PID -> PID. There
two cases

Case 1: PKT.NHOSTS is zero
This will be the case when the neighbor host has just come up
is on a different net or subnet. Set NEIGHBOR-ADDRESS ->
and call the ROUTE procedure, which will return the
ID. Then call the UPDATE procedure. In the case
errors, do nothing but return

Case 2: PKT.NHOSTS is nonzero
This is the case when the neighbor host is on the same net
subnet. First, save the values of DELAY and OFFSET in
variables F and G. Then, for each value of HID from zero
NHOSTS-1 consider the corresponding PKT.HOSTS-TABLE entry and
the following: Set F + PKT.HOST-TABLE.DELAY -> DELAY
G + PKT.HOST-TABLE.OFFSET -> OFFSET and call the UPDATE procedure
This completes processing

ROUTE
This procedure returns the host ID in HID of the host
by the global variable ADDRESS

1. First, determine if the host represented by ADDRESS is on the
local net as LOCAL-ADDRESS. For the purposes of
comparison bits 0-7 and 16-31 are compared for class-A
and bits 8-31 are compared for class-B and class-C nets.
provides for a subnet capability, where the bits 0-7 and 16-23
(class-A) or 8-15 (class-B) are used as a subnet number

DCN Local-Network Protocols Page 20
D.L.

Case 1: The host is on the same net or subnet
Extract the address field of ADDRESS, subtract ADDRESS-OFFSET
store the result in HID. If 0 <= HID < NHOSTS, the
completes normally; otherwise it terminates in an
condition

Case 2: The host is not on the same net or subnet
Search the NET-TABLE for a match of the net fields
LOCAL-ADDRESS and NET-TABLE.NET. If found
NET-TABLE.HID -> HID and return normally. If the NET-TABLE.
field is zero, indicating the last entry in the table,
HET-TABLE.HID -> HID and return normally. Note that, in the
of hosts including GGP/EGP gateway modules, if no match is
the procedure terminates in an error condition

UPDATE
This procedure updates the entry of HOST-TABLE indicated by HID
three global variables: DELAY, OFFSET and PID. Its purpose is to
the HOST-TABLE entry corresponding to host ID HID. In the following
references are to this entry

1. If PID is not equal to HOST-TABLE.PID, the route to host HID is
via the net-output process associated with this HELLO process.
this case, if DELAY + MINDELAY > HOST-TABLE.DELAY, the path is
than one already in HOST-TABLE, so the procedure does nothing

2. This step is reached only if either the route to host HID is via
net-output process associated with this HELLO process or the
reported path to this host is shorter by at least MINDELAY.
There are two cases

Case 1: HOST-TABLE.DELAY < MAXDELAY
The existing path to host HID is up and this is a point-to-
link (HLO.BROADCAST is set to zero). If DELAY < MAXDELAY
newly reported path is also up. Proceed to the next step
Otherwise, initiate a hold-down cycle by
MAXDELAY -> HOST-TABLE.DELAY
HOLD-DOWN-INTERVAL -> HOST-TABLE.TTL and return

Case 2: HOST-TABLE.DELAY >= MAXDELAY
The existing path to host HID is down. If DELAY < MAXDELAY
HOST-TABLE.TTL is zero, the hold-down period has expired and
newly reported path has just come up. Proceed to the next step
Otherwise simply return

3. In this step the HOST-DELAY entry is updated.
DELAY -> HOST-TABLE.DELAY, HOLD-DOWN-INTERVAL -> HOST-TABLE.TTL
HLO.PID -> HOST-TABLE.PID

DCN Local-Network Protocols Page 21
D.L.

4. For precise timekeeping, the offset can be considered valid only
the length of the last HELLO packet transmitted is equal
the length of the last one received. Thus, if HLO.
equal to PKT.LENGTH, set OFFSET -> HOST-TABLE.OFFSET
otherwise, leave this field alone. Finally, if HID is equal
CLOCK-HID and bit 15 (the DATE-VALID bit)
of DATE is zero, set PKT.DATESTAMP -> DATE and call the SET-
procedure of the CLOCK process with argument HLO.TIMESTAMP

OUTPUT-PACKET
This event is evoked once every HELLO-INTERVAL seconds. It determines
a HELLO message is to be transmitted, transmits it and updates
variables

1. If HLO.KEEP-ALIVE is nonzero decrement its value

2. If HLO.POLL is zero and HLO.KEEP-ALIVE is zero, do not send a
message. If either is nonzero initialize the packet fields
follows: LOCAL-ADDRESS -> PKT.SOURCE
HLO.NEIGHBOR-ADDRESS -> PKT.DESTINATION and DATE -> PKT.DATESTAMP
Note: PKT.DESTINATION is set to zero if this is a broadcast
(HLO.BROADCAST set to one). Also, note that bit 15 of DATE is
DATE-VALID bit. If this bit is one the receiver will not update
master clock from the information in the transmitted packet
This is significant only if the sending host is on
least-delay path to the master clock. Set PKT.TIMESTAMP
the value returned from the READ-CLOCK procedure.
HLO.KEEP-ALIVE is zero or HOLD is nonzero, set PKT.TSP
zero; otherwise, set PKT.TIMESTAMP + HLO.TSP -> PKT.TSP

3. Determine if the neighbor is on the same net or subnet. If
neighbor is on a different net set PKT.NHOSTS to zero
proceed with the next step. Otherwise, set NHOSTS ->
PKT.NHOSTS and for each value of HID from zero to PKT.HOSTS-1
copy the HOST-TABLE.DELAY and HOST-TABLE.OFFSET fields of
corresponding HOST-TABLE entry in order into the packet.
each entry copied test if the HOST-TABLE.PID field matches
HLO.PID of the HELLO process. If so, a potential routing
is possible. In this case use MAXDELAY for the delay field
the packet instead.

4. Finally, set HLO.LENGTH to the number of octets in the packet
and send the packet

3.4. HOST Process (HOS

This process maintains the routing tables. It is activated once
second to scan HOST-TABLE and decrement the HOST-TABLE.TTL field of
entry. It also performs housekeeping functions

DCN Local-Network Protocols Page 22
D.L.

3.4.1. Local

HOS.
This is an eight-bit integer used to identify the HOST process. It
initialized by the kernel when the process is created and
unchanged thereafter

HOS.
This is an eight-bit temporary variable

3.4.2. Events and

SCAN
This event is evoked once each second to scan the HOST-TABLE and
housekeeping functions

1. For each value of a temporary variable F from zero to NHOSTS-1 do
following: Set LOCAL-ADDRESS -> ADDRESS and call the
procedure, which will return the host ID HID. If F is
to HID, then set both DELAY and OFFSET to zero, HOS.PID ->
and call the UPDATE procedure. This will cause all
received with the local address to be routed to this process

If HOST-TABLE.TTL is zero skip this step. Otherwise,
HOST-TABLE.TTL by one. If the result is nonzero skip
remainder of this step. Otherwise, If HOST-TABLE.DELAY HOLDOFF-INTERVAL -> HOST-TABLE.TTL and MAXDELAY -> HOST-TABLE.DELAY
The effect of this step is to declare a hold-down cycle when a
goes down

4.

1. Mills, D.L. Final Report on Internet Research, ARPA Packet
Program. Technical Report TSLAB 82-7, COMSAT Laboratories,
December 1982.

DCN Local-Network Protocols Page 23
D.L.

Appendix A. Link-Level Packet

A.1. Serial Links Using Program-Interrupt

Following is a description of the frame format used
asynchronous and synchronous serial links with program-
interfaces such as the DEC DLV11 and DPV11. This format
transparency coding for all messages, including HELLO messages,
does not provide error detection or retransmission functions. It
designed to be easily implemented and compatible as far as
with standard industry protocols

The protocol is serial-by-bit, with the same interpretation
the order of transmission as standard asynchronous and
interface devices; that is, the low-order bit of each octet
transmitted first. The data portion of the frame consists of
Internet datagram encoded according to a "character-stuffing
transparency convention

1. The frame begins with the two-octet sequence DLE-STX, in the case
asynchronous links, or the four-octet sequence SYN-SYN-DLE-STX, in
case of synchronous links. The data portion is transmitted next
encoded as described below, followed by the two-octet
DLE-ETX. No checksum is transmitted or expected. If it
necessary for any reason to transmit time-fill other than in
data portion, the DEL (all ones) is used

2. Within the data portion of the frame the transmit buffer
scanned for a DLE. Each DLE found causes the sequence DLE-DLE
be transmitted. If it is necessary for some reason for
transmitter to insert time-fill within the data portion,
sequence DLE-DEL is used.

3. While scanning the data stream within the data portion of
frame the sequence DLE-DLE is found, a single DLE is inserted
the receive buffer. If the sequence DLE-ETX is found, the
is passed on for processing. The sequence DLE-DEL is discarded
Any other two-octet sequence beginning with DLE and ending
other than DLE, ETX or DEL is considered a protocol error
(see note below).

Note: In the case of synchronous links using program-
interfaces such as the DPV11, for example, a slightly
protocol is suggested when both ends of the link concur.
interfaces typically provide a parameter register which can be
with a code used both to detect the receiver synchronizing pattern
for time-fill when the transmit buffer register cannot be serviced
time for the next character

The parameter register must be loaded with the SYN code for
protocol to work properly. However, should it be necessary
transmit time-fill, a single SYN will be transmitted, rather than
DLE-DEL sequence specified. Disruptions due to these events can
minimized by use of the following rules

DCN Local-Network Protocols Page 24
D.L.

1. If the transmitter senses a time-fill condition (usually by
control bit assigned for this purpose) between frames
immediately following transmission of a DLE, the condition is ignored

2. If the transmitter senses a time-fill condition at other times it
the sequence DLE-CAN

3. If the receiver finds a SYN either between frames or
following DLE, the SYN is discarded without affecting
decoding.

4. If the receiver finds the sequence DLE-CAN in the data portion,
discards the sequence and the immediately preceding octet

These rules will work in cases where a single SYN has
inserted by the transmitter and even when a SYN has been inserted
the DLE-CAN sequence. If an overrun (lost data) condition is
at the receiver, the appropriate action is to return to
initial-synchronization state. This should also be the action if
code other than STX is found following the initial DLE. or if
code other than DLE, ETX, DEL or CAN is found following a DLE in
data portion

A.2. Serial Links Using DDCMP

Following is a description of the frame format used on DEC DDCMP
with DMA interfaces such as the DEC DMV11 and DMR11. These
implement the DEC DDCMP protocol, which includes error detection
retransmission capabilities. The DDCMP frame format is as follows

+-------------+-----+-----+-----+-----+-----+------+------+------+
| SYN SYN SOH |Count|Flag |Resp | Seq | Adr | CRC1 | Data | CRC2 |
+-------------+-----+-----+-----+-----+-----+------+------+------+
bits 24 14 2 8 8 8 16 ... 16

With respect to this diagram, each octet is transmitted starting from
leftmost octet, with the bits of each octet transmitted low-order bit first
The contents of all fields except the "Data" field are managed by
interface. The Internet datagram is placed in this field as-is, with
character or bit stuffing (the extent of this field is indicated by
interface in the "Count" field

A.3. Serial Links Using HDLC

Following is a description of the frame format used on HDLC links
program-interrupt interfaces such as the DEC DPV11.

+--------+--------+--------+--------+--------+--------+
| Flag | Addr | Ctrl | Data | CRC | Flag |
+--------+--------+--------+--------+--------+--------+
coding 01111110 00000000 00000000 xxxxxxxx cccccccc 01111110

DCN Local-Network Protocols Page 25
D.L.

With respect to this diagram, each octet is transmitted starting
the leftmost octet, with the bits of each octet transmitted low-
bit first. The code xxxxxxxx represents the data portion and
represents the checksum. The bits between the "Flag" fields
encoded with a bit-stuffing convention in which a zero bit is
following a string of five one bits. The "Addr" and "Ctrl" fields
not used and the checksum is ignored. The Internet datagram is
in the "Data" field, which must be a multiple of eight bits in length

A.4. ARPANET 1822 Links Using Local or Distant Host

Following is a description of the frame format used with
1822 Local or Distant Host interfaces. These interfaces can be
to connect a DCN host to an ARPANET IMP, Gateway or Port Expander
to connect two DCN hosts together. When used to connect a DCN host
an ARPANET IMP, Gateway or Port Expander, a 96-bit 1822 leader
prepended ahead of the Internet datagram. The coding of this
is as described in BBN Report 1822. When used to connect two
hosts together, no leader is used and the frame contains only
Internet datagram

A.5. ARPANET 1822 Links Using HDH

Following is a description of the frame format used with
1822 HDH interfaces. These interfaces can be used to connect a
host to an ARPANET IMP or Gateway or to connect two DCN
together. In either case, the frame format is as described
Appendix J of BBN Report 1822.

A.6. X.25 LAPB Links Using RSRE

Following is a description of the frame format used on X.25
links with the Royal Signals and Radar Establishment interfaces
These interfaces implement the X.25 Link Access Protocol -
(LAPB), also known as the frame-level protocol, using a frame
similar to that described under A.3 above. Internet datagrams
placed in the data portion of I frames and encoded with
bit-stuffing procedure described in A.3. There is no packet-
format used with these interfaces

A.7. Ethernet

Following is a description of the frame format used on Ethernet links

+-----------+-----------+------+------+-----+
| Dest Addr | Srce Addr | Type | Data | CRC |
+-----------+-----------+------+------+-----+
bits 48 48 16 ... 32

With respect to this diagram, each field is transmitted starting
the leftmost field, with the bits of each field transmitted low-
bit first. The "Dest Addr" and "Srce Addr" contain 48-bit
addresses, while the "Type" field contains the assigned value for
datagrams (0800 hex) or

DCN Local-Network Protocols Page 26
D.L.

ARP datagrams (0806 hex). The Internet datagram is placed in
"Data" field and followed by the 32-bit checksum. The
Resolution Protocol (ARP) is used to establish the mapping
Ethernet address and Internet addresses

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