DECnet Phase IV forced a radical change in the Routing component of
DECnet. Larger networks forced introduction of hierarchical routing
while LANs introduced the use of multicast messages.
While Routing underwent large scale changes, the Network Service
Protocol (NSP) and Session Control only received a minor facelift from
their DECnet Phase III definitions and most of those changes were due
to the larger addresses in Routing.
- Routing V2.0 specifies the
functions, interfaces, and protocols for controlling the routing of
messages within DECnet communications networks.
Even though Session Control is defined separately from NSP, DECnet
Phase IV implementations rarely code Session Control as a distinct
component but instead merge it into their implementation of NSP.
- Network Service Protocol V4.0
specifies the functions, interfaces, and protocols for handling the
creation and destruction of logical links, error control, and flow
- Session Control V1.0
describes the functions, interfaces, operation, and protocols relating
to creating, maintaining, and destroying logical links. A logical
link is a virtual connection between two user-level software modules
(end users) in the same node or in different nodes of the same
One of the important aspects of DECnet has the been the existence of
network management tools which act the same independent of the DECnet
platform. Having a well defined and complete network management
specification has allowed DECnet Phase IV to carry on in this
Network management is not just the ability to manage your own DECnet
node but also encompasses remote network management, event logging,
and loopback at the datalink and application levels. These
capabilities, while more common now, were rare in networking protocols
when DECnet Phase IV came out (though DECnet Phase III also contained
some of these capabilities).
Maintenance Operations (MOP) is far more important to DECnet than the
abstract below indicates. MOP is used to downline load software to
routers and servers, even servers that don't run DECnet. MOP also
allows network managers to connect routers and servers using a feature
of MOP called Console Carrier Requester (CCR).
- Network Management V4.0
describes the functions, structures, protocols, algorithms, and
operation of the DIGITAL Network Architecture Network Management
modules. It is a model for DECnet implementations of Network
Management software. Network Management provides control and
observation of DECnet network functions to users and programs.
- Maintenance Operations V3.0
describes the structure, functions, interfaces, and protocols needed
for the low level maintenance of a DECnet network.
There have been three basic applications common to data networks:
remote file access, remote terminal access, and electronic mail.
While remote file and terminal access are defined by the Digital
Network Architecture, electronic mail is not.
Not coincidentally DECnet has remained remarkably consistent in its
file transfer and remote terminal access protocol but electronic mail
has gone in two directions, VMSmail (also called Mail-11) and Message
Router / MAILBUS. Which is why no electronic mail protocols are
The seamless integration of remote file access under VMS (and in the
past, RSX-11) has long been one the major successes of DECnet. This
is due in no small part to the file access protocol used by DECnet
which allows a very rich set of file access functions:
DECnet Phase IV introduced a new remote terminal protocol,
CTERM, for use on Phase IV systems. However CTERM never
really lived up to its expectations but it did manage to get
implemented on most of the major DECnet Phase IV platforms.
- Data Access Protocol (DAP)
V5.6 provides standardized formats and procedures for
accessing and passing data between a user process and a file system
existing in a network environment.
CTERM is defined by two specifications:
- Command Terminal V1.4 describes a
model for communication between terminal-handling subsystems and
operating systems in a communications network.
- Terminal Foundation V2.5
describes a model for primitive terminal-handling services in Digital
systems. These services are independent of the specific use (e.g.
command handling, forms, editing) being made of the terminal and
include: connection management, mode changing, and local
Looking back, most of the architects and implementors of DECnet Phase IV
would probably agree to a few changes to the architecture for DECnet Phase
The first change to the architecture would be to not have a
DECnet Phase IV system change the Ethernet physical address of the
machine. A DECnet Phase IV system currently changes its Ethernet
physical address to the form of AA-00-04-00-xx-yy where xx-yy is
derived from the Phase IV address of the machine. This allowed for
simple router-less LAN operation since the LAN address of the remote
could be deduced from its Phase IV address. However this caused many
problems on systems running multiple protocols, especially ones that
do not support the dynamic switching of the Ethernet physical address
of the system.
This became quite apparent when the mechanisms of running DECnet Phase
IV over Token Ring (IEEE 802.5) network were being developed. Many
Token Ring system also want to their Token Ring physical address to
something decided by their network administrator. This is in obvious
conflict with how DECnet wants to operate. This resulted in a change
to DECnet Phase IV such that on Token Ring the existing physical
address remains unchanged even when DECnet is running.
The second change would be to have given DECnet Phase IV a larger
address space. While in the early 1980s a 16 bit address space seemed
like a huge number, today that number seems quite small. Even the
TCP/IP protocol family with a 32-bit address is now beginning to
strain the limits of its address space after only a decade.
Indeed, a DECnet Phase IV network would fit easily within an IP Class
B network. It is interesting to speculate what effect a larger address
space would have had on DECnet Phase IV.