Updated: 24 May 2001

DECnet-Plus for OpenVMS
Introduction and User's Guide

DECnet-Plus for OpenVMS implements standards approved by:

• The International Telegraph and Telephone Consultative Committee (CCITT)
• The Institute for Electrical and Electronic Engineers (IEEE)
• The Internet Engineering Task Force (IETF)

Table 1-2 lists the OSI standards that DECnet-Plus for OpenVMS supports. Note that for LANs at the Data Link and Physical layers, ISO standards are equivalent to IEEE standards.

Table 1-2 OSI Standards Supported by DECnet-Plus for OpenVMS

Layer	Standard	Description
	ISO 7498	Basic Reference Model
Application	ISO 8571	File Transfer, Access and Management (FTAM)
	ISO 8649	Service Definition --- Association Control
	ISO 8650	Association Control Service Element (ACSE)
	ISO 9041	Virtual Terminal Protocol
	ISO 9072	Remote Operations Service Element
Presentation	ISO 8822	Presentation Service
	ISO 8823	Presentation (Kernel)
Session	ISO 8326	Connection-Oriented Network Service (CONS)
	ISO 8327	Connection-Oriented Network Service Protocol
	ISO 9595	Common Management Information Service Element (CMISE)
Transport	ISO 8072	Connection-Oriented Transport Service (COTS) Definition
	ISO 8073	Connection-Oriented Transport Service (COTS) Protocol
	RFC 1006	Defines how to implement ISO 8073 Transport Class 0 on top of TCP
	RFC 1006 Extension (Internet Draft)	Defines how to implement ISO 8073 Transport Class 2 non-use of Explicit Flow Control on top of TCP
Network	ISO 7498 Addendum 1	Connectionless-Mode Transmission
	ISO 8208	X.25 Packet Level Protocol (PLP)
	ISO 8348	Service definition: Connection-Oriented Network Service (CONS)
	ISO 8348 Addendum 2	OSI addressing formats
	ISO 8473, 8348 Addendum 1	Connectionless-Mode Network Service (CLNS)
	ISO 8878	X.25/Connection-Oriented Network Service (CONS)
	ISO 8881	X.25 Packet Level Protocol in local area networks
	ISO 9542	End-system to intermediate-system routing exchange protocol
Data Link	ISO 3309, 4335, 7809, 8471, 8885	Point-to-point data links (HDLC)
	ISO 7776	Point-to-point X.25 data links (only with an X.25 license; LAPB, one possible user)
	ISO 8802-1 (IEEE 802.1) 1	Ethernet support (CSMA-CD)
	ISO 8802-2 (IEEE 802.2)	Frame formats for 8802-3 LANs (CSMA-CD logical link control (LLC1))
		X.25 logical link control (LLC2) (one possible user)
	ISO 8802-3 (CSMA/CD)	LAN support (CSMA-CD)
	ISO 9314	Fiber Distributed Data Interface (FDDI)
Physical	ISO 8802-3 (IEEE 802.3)	CSMA-CD devices
	ISO 9314	Fiber Distributed Data Interface (FDDI)
	EIA RS-232-C	HDLC point-to-point devices
	EIA RS-422	HDLC point-to-point devices
	EIA RS-423	HDLC point-to-point devices
	CCITT V.35	HDLC point-to-point devices

The DECnet-Plus for OpenVMS software has several related dependencies outlined in the following sections.

1.3.1 DECnet Licenses

To use DECnet-Plus for OpenVMS or DECnet Phase IV software, you need the appropriate software licenses. Table 1-3 lists the two basic licenses and three license keys for OpenVMS VAX and Alpha systems, for DECnet Phase IV and DECnet-Plus, respectively.

Table 1-3 DECnet Phase IV and DECnet-Plus Licensing

VAX Phase IV	VAX DECnet-Plus	Alpha Phase IV	Alpha DECnet-Plus
End System License
DVNETEND	DVNETEND	DVNETEND	DVNETEND
All DECnet Phase IV functionality except cluster alias and routing	All DECnet Phase IV functionality except cluster alias, OSI API 1, OSI application gateways, DECdns server, and routing	All DECnet Phase IV functionality except cluster alias	All DECnet-Plus functionality except cluster alias, OSI API 1, OSI application gateways, and routing
Extended Function License
DVNETRTG	DVNETRTG	DVNETEXT	DVNETEXT
All DECnet Phase IV functionality including cluster alias 2 and routing	All DECnet-Plus functionality including cluster alias 2, OSI API, OSI application gateways, DECdns server, and host-based routing 3	All DECnet Phase IV functionality including cluster alias 2 but excluding routing 4	All DECnet-Plus functionality including cluster alias 2, OSI API, OSI application gateways, and host-based routing 3

For mapping between node names and node addresses, you need at least one of the following three name services:

• Local namespace
• DECdns
• DNS/BIND

A DECnet-Plus network can use one name service exclusively, or it can have a mixture of systems using one or more of the name services. While configuring DECnet-Plus, you specify one or more of the three available name services to use on the node. To determine which name service(s) to use, check which name services are already being used by other nodes in your network. For example, if the other nodes in your network are already using DECdns, you will most likely want to use DECdns and join the existing namespace. The following sections include additional criteria and dependencies on the name services.

1.3.2.1 Choosing the Local Namespace

Choose the Local namespace if you have a small network and do not wish to use a distributed namespace. The Local namespace is similar to the permanent node database (NETNODE_REMOTE.DAT), used on DECnet Phase IV systems. With the Local namespace, name-to-address mapping information has to be administered separately on each node. To use the Local namespace, no additional software is required.

1.3.2.2 Choosing DECdns

With DECdns, all node names in the network can be administered from one location. The mapping information is stored on two or more DECdns servers and kept up-to-date networkwide automatically. DECnet-Plus requires at least two DECdns servers in the network. DECdns server software must be installed and configured on these systems (the server software is optional software included with the DECnet-Plus for OpenVMS software kit). The DECnet-Plus Planning Guide describes planning considerations and the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration and DECnet-Plus DECdns Management guides include installation and configuration instructions.

1.3.2.3 Choosing DNS/BIND

DNS/BIND, the distributed name service for TCP/IP, supports the storage of IP addresses and the use of node synonyms. Node synonyms allow for backward compatibility with older applications that cannot use long domain names. (Note that DECnet-Plus also allows for node synonyms to provide backward compatibility with DECnet Phase IV node names.) DNS/BIND is needed if you want DECnet-Plus to run applications over TCP/IP. To use the DNS/BIND name service, DECnet-Plus requires one or more DNS/BIND servers in the network. DNS/BIND must be selected as one of the name services if you plan to use the DECnet over TCP/IP or OSI over TCP/IP features. See the appropriate TCP/IP documentation for more information on DNS/BIND.

1.3.3 DECdts Time Server

The DIGITAL Distributed Time Service (DECdts) synchronizes the system clocks in computers connected by a network. The DECnet-Plus for OpenVMS configuration procedure autoconfigures the DECdts clerk. If your network uses multiple DECdns servers, or if you need network clock sychronization, DIGITAL recommends that you install at least three DECdts servers on each LAN. See the DECnet-Plus DECdts Management guide for more information.

1.3.4 Intermediate System

In large networks and networks requiring high throughput, one or more dedicated routers are recommended for the network. DIGITAL recommends using host-based routers to replace DECnet Phase IV host-based routers or in environments not requiring high throughput.

1.3.5 X.25

The DECnet-Plus for OpenVMS VAX systems license includes the right to use X.25 Access software (formerly known as VAX P.S.I. Access) or X.25 Native mode software (formerly known as VAX P.S.I.), which requires an additional license.

The X.25 software in DECnet-Plus for OpenVMS is backwards compatible with systems running the older VAX P.S.I. products. For further information on X.25, refer to Chapters 2 and 4.

On DECnet-Plus for OpenVMS Alpha systems, the following licenses are required:

• To run CONS over LLC2 or CLNS over DIGITAL HDLC, a DECnet-Plus for OpenVMS Alpha license is required.
• To use LAPB to a WAN and to use any of the X.25 APIs or utilities over either LAN or WAN, an X.25 for OpenVMS Alpha systems license is required.

To develop OSI applications, you need to use the OSI application development interfaces (API) installed with the base system. These tools allow you to build network applications that adhere to the OSI standards defined by the International Organization for Standardization (ISO).

You can use the following components in building OSI applications:

• An application programming interface (API) to the File Transfer, Access and Management (FTAM) services within the Application layer
• The OSI Applications Kernel (OSAK) API, which provides access to:
  • Presentation layer services
  • The Association Control Service Element (ACSE) of the Application layer
• The Remote Operations Service Element (ROSE) of the Application layer

Where ISO standards exist, the APIs conform to these standards.

The following table shows the components available on DIGITAL UNIX and OpenVMS platforms.

Operating System	Components
DIGITAL UNIX	FTAM, OSAK (Presentation and ACSE)
OpenVMS	FTAM, OSAK (Presentation and ACSE), ROSE (VAX only)

1.4 Distributed Networking

A DECnet-Plus network can be viewed as a distributed processing system. The major functions of the network, such as network management and routing, are not centralized in a single system. Each system can manage both itself and remote systems. Adaptive routing eliminates the need to set up network data paths.

Some of the primary features of the DECnet-Plus distributed network are:

• Optional use of distributed system services for networkwide names and synchronized time
• Support for distributed network applications

Networkwide capabilities include the optional use of distributed system services designed to make the network as transparent as possible to users and applications. The DECnet-Plus distributed computing environment provides the following services:

• Global naming (see the DECnet-Plus Planning Guide)
• Time synchronization (see the DECnet-Plus Planning Guide)

In the DECnet-Plus distributed processing environment, you can physically distribute multiple resources or tasks that perform various functions between systems on the network.

A distributed application is a collection of processes that use resources, such as processing elements, databases, and physical devices, located on other systems in the network. As a single logical application, the elements or tasks are physically divided. A task is a modular component of work that the application programmer defines within an application. The work of a distributed application is divided among tasks that can communicate with each other.

In an OpenVMS operating system, a task is executed within the context of a process. The process context defines the environment in which the task executes. OpenVMS software controls the access and allocates the resources required by the task, based on the process context.

In a distributed application, each task is distinct and can be placed in different locations in the network. The system interface for the application allows you to run the application locally or remotely without any apparent difference.

You can distribute an application so that each task is assigned to a system with appropriate resources. For instance, one task computes on a powerful processor while another stores the information in a database on a system with extensive disk storage capabilities. A common example of a distributed application is an implementation of the client/server model, such as DECdns, in which the client task (on the DECdns clerk system) requests service from the server task on a different system (the DECdns server).

Interprocess communication is the movement of data and control from one task running within a process to another task in the network. Interprocess communication allows the various tasks on the different processes to cooperate and communicate with each other, exchanging message packets over the connection established between the tasks.

Distributed applications can increase availability. You can design a distributed application to avoid a single point of failure by moving tasks to other processors if a processor fails. Other benefits of distributed applications include:

• Load and resource sharing
• Reduced communication costs
• Modular, incremental growth capabilities
• Configuration flexibility capabilities

An OpenVMS cluster configuration is an organization of OpenVMS operating systems that communicate over a high-speed communications path and share processor resources as well as disk storage. DECnet connections are required for certain OpenVMS cluster tools and configurations. DECnet-Plus for OpenVMS software provides support for OpenVMS cluster systems.

1.5.1 DECnet-Plus OpenVMS Cluster Alias

DECnet-Plus for OpenVMS supports the use of multiple cluster aliases. The alias node identifier (a node name or node address) is common to some or all nodes in the cluster and permits users to address it as though it were one node.

For management purposes, the cluster alias is viewed by the DECnet-Plus software as a separate Node entity that is manageable through NCL commands. The Alias entity differs from a regular Node entity in some characteristics; for example, the Alias entity does not support a Circuit entity. The cluster alias appears to the network as a multicircuit end node, which is an end node with several active circuits. In an OpenVMS cluster system that consists of DECnet-Plus for OpenVMS systems on a LAN, the alias node appears as an end node with multiple points for attachment to the LAN.

DECnet-Plus for OpenVMS supports the ability to access nodes in an OpenVMS cluster using a separate alias node address, while retaining the ability to address each node in the cluster individually. Not all network objects may be accessed using this mechanism. The maximum number of nodes supported for a cluster alias is 96. The maximum number of cluster aliases for a single node is three.

1.5.2 OpenVMS Cluster Configuration Procedure

The cluster_config.com command procedure for performing a OpenVMS cluster configuration invokes the DECnet-Plus for OpenVMS net$configure.com command procedure to perform any required modifications to NCL initialization scripts. Use cluster_config.com to create a configuration for each satellite node in the cluster.

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6501PRO_001.HTML