HP OpenVMS Systems

Ask the Wizard
» 

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

Quick Links

» Non-javascript page
» Ask the Wizard
» OpenVMS FAQ

Test Drive OpenVMS

» OpenVMS I64 test drive
» Java test drive

Other information resources available to you include:

» OpenVMS freeware
» ECO kits, software and hardware support, prior version support
» Alpha SRM, ARC, and AlphaBIOS firmware updates
» ENCOMPASS - HP user group
» OpenVMS software downloads, OpenVMS freeware CD-ROM
» OpenVMS firmware locations
» DECconnect passive adaptor charts
» Cables reference guide
» MicroVAX console commands
» OpenVMS student research

Select a topic below to see Questions Frequently Asked by partners

» Using the online documentation library(installing BNU from the asap SDK)
» Global sections(how to create and use.)
» xx$CREATE_BUFOBJ system service(usage)
» Ethernet address(methods of determination)
» Shareable images(cookbook approach to creating one)
» Sharing data/code at absolute addresses(a guide with examples)
» Determining the Alpha microprocessor
» Using GETSYI to get hardware status

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

The Decnet phase IV specifications

The Digital Network Architecture (DNA) is a set of specifications that defines DECnet. This page describes a subset of those specifications which define DECnet Phase IV. In addition to the specifications and their descriptions, a small amount of background information about DECnet Phase IV in provided to help choose which specification, if any, might be of interest.

Please be aware that all of the DECnet Phase IV specifications are simple text files. They were written in the dark ages of computer history before the widespread introduction of WYSIWYG editors.

Introduction

DECnet Phase IV was first released by Digital in 1983 for its VMS and RSX-11 systems. Since then it has been implemented on just about every operating system Digital ever shipped including ULTRIX, VAXeln, RSTS/E, TOPS-20, and TOPS-10; the significant exception was RT-11.

Two of major advancements of DECnet Phase IV over DECnet Phase III were support for larger networks (63 areas of 1023) nodes and the use of Ethernet as a datalink. DECnet Phase III limited the entire network to a maximum of 255 nodes. DECnet Phase III also only supported point-to-point and multi-drop links which meant it could not cope the coming introduction of LANs to the marketplace.

Datalinks

DECnet Phase IV still used DDCMP as the basis for its point-to-point links though DDCMP was enhanced to make better use of high-bandwidth and high-latency links such as satellite links.

  • DDCMP V4.1 describes a data link control procedure that ensures a reliable data communication path between communication devices connected by data links. DDCMP has been designed to operate over full and half-duplex synchronous and asynchronous channels in both point-to-point and multipoint modes.
However Ethernet was the new datalink of choice for DECnet Phase IV systems. And we had the specification to make sure it worked.
  • DNA Ethernet V1.0 describes the structure, functions, interfaces, and protocols of the DNA Ethernet Data Link not defined in the Ethernet Specification that make it compatible with DNA.
  • Ethernet Node Product V1.0 specifies the minimum required functions for a DEC node connected to an Ethernet. A node meeting these requirements will be maintainable and usable to build additional product specific functions.

Routing, NSP, and session control

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.

  • Routing V2.0 specifies the functions, interfaces, and protocols for controlling the routing of messages within DECnet communications networks.
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.

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 control.
  • 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 network.

Network Management

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 regard.

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).

  • 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 (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).
  • Maintenance Operations V3.0 describes the structure, functions, interfaces, and protocols needed for the low level maintenance of a DECnet network.

Application Protocols

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 described here.

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:

  • 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.
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.

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 characteristics management.

LAT (local area transport)

At the same time that DECnet Phase IV was released, Digital introduced a new LAN based protocol for terminal access called LAT (Local Area Terminal). This protocol was revolutionary and Digital was awarded a patent for it. LAT remains to this day a proprietary protocol for which specifications are not available without license.

In hindsight

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 IV.

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.

The last word

All the protocols mentioned above (except for LAT), even though developed by Digital, are not proprietary to Digital. Anyone can implement them without seeking permission from or paying royalties to Digital.

Eventually a number of enhancements were made to DECnet Phase IV. These enchancements become known as DECnet Phase IV+. DECnet Phase IV+ systems were completely interoperable with DECnet Phase IV. In fact most DECnet Phase IV systems are actually DECnet Phase IV+ systems. Most of the enhancements were performance improvements such as the addition of path splitting in Routing and the addition of delayed ACKs and a out of order cache in NSP. There was, however, one significant new functional enhancement: the addition of proxies in Session Control. Note that none of the DECnet Phase IV+ changes are covered in any of the above specifications.

Comments or suggestions for this page are welcome