Jane C. Blake,
Ten years ago, a network of 200 nodes was considered very large and of
uncertain manageability. Today, Digital's networks accommodate 100,000
nodes in open, distributed system environments and resolve the complexities
of incompatibility among multivendor systems. Ten years from today, network
systems comprising a million-plus nodes will be built based upon the
Digital architectures and technologies described in this issue.
John Harper provides an informative overview of advances made with each
phase of the Digital Network Architecture, now in Phase V. He describes
the architectural layers and distinguishes Digital's approach to network
services and management from that of others in the industry. His paper
offers context for those that follow.
The Phase V architecture provides the migration to open systems from
previous phases of DECnet. In implementing Phase V, designers of two
DECnet products for the OpenVMS and ULTRIX operating systems shared
several goals: extend network access in a multivendor environment, use
standard protocols, and protect customers' software investments. Larry
Yetto, Dotsie Millbrandt, Yanick Pouffary, Dan Ryan, and David Sullivan
describe the DECnet/OSI for OpenVMS implementation and give details of
the significantly different design of Phase V network management. In their
paper on DECnet/OSI for ULTRIX, Kim Buxton, Ed Ferris, and Andrew Nash
stress the importance of the protocol switch tables in a multiprotocol
environment. DECnet/OSI for ULTRIX incorporates OSI, TCP/IP, and X.25.
In the broadly accepted TCP/IP protocol area, Digital has developed a high-
performance TCP/IP implementation that takes advantage of the full FDDI
bandwidth. K.K. Ramakrishnan and members of the development team review the
characteristics of the Alpha AXP workstation, OSF/1 operating system, the
protocols, and the network interface. They then detail the optimizations
made for high-performance.
Routing data through networks with thousands of nodes is a very difficult
task. Radia Perlman, Ross Callon, and Mike Shand describe how the Phase V
routing architecture addresses routing complexity. Focusing on the IS-IS
protocol, they pose problems a routing protocol could experience, present
alternative solutions, and explain the IS-IS approach.
The challenges in developing multiprotocol routing software for
internetworking across LANs, WANs, and dial-up networks are presented in
the paper by Graham Cobb and Elliot Gerberg. They highlight the importance
of the stability of the routing algorithms, using the DEC WANrouter and
DECNIS products as a basis for discussing alternative designs. Stewart
Bryant and David Brash then focus on details of the high-performance DECNIS
500/600 bridge/router and gateway. They discuss the architecture and the
algorithm for distributed forwarding that increases scalable performance.
Both the hardware and the software are described.
In addition to routing, the subject of data transfer of high-speed,
bursty traffic using a simplified form of packet switching is described.
Robert Roden and Deborah Tayler discuss frame relay networks, their unique
characteristics, and the care needed in protocol selection and congestion
The above discussions of data transfer and routing occur at the lower
layers of the network architecture. Dave Robinson, Larry Friedman,
and Scott Wattum present an overview of the upper layers and describe
implementations that maximize throughput and minimize connection delays.
Network management is critical to the reliable function of the network. As
Mark Sylor, Frank Dolan, and Dave Shurtleff tell us in their paper, Phase
V management is based on a new architecture that encompasses management
of the network and systems. They explain the decision to move management
responsibility to the subsystem architecture, and also describe the entity
model. The next paper elaborates on the director portion of the management
architecture, called the DECmcc Management Director. Colin Strutt and
Jim Swist review the design of this platform for developing management
capabilities, the modularity of which allows future modules to be added
The editors thank John Harper for his help in selecting the content of this