DCN Local-Network Protocols
RFC 891

Document Type RFC - Internet Standard (December 1983; No errata)
Also known as STD 44
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 891 (Internet Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                   D.L.  Mills
Request for Comments:  891                              December 1983

                         DCN Local-Network Protocols

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

1.  Introduction

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

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

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

2.  Narrative Description

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

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


DCN Local-Network Protocols                                         Page 2
D.L. Mills

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

     Each virtual host can support multiple internet protocols,
connections and, in addition, a virtual clock.  Each physical host
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 is
assumed to be reset each day at 0000 hours UT.  Not all physical hosts
implement the full 32-bit precision; however, in such cases the
resolution of the logical clock may be somewhat less.

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

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

     The links connecting the various physical hosts together and to
foreign nets can be distributed in arbitrary ways, so long as the net
Show full document text