HP OpenVMS Systems Documentation

DECnet-Plus for OpenVMS is an implementation of Phase V of the DIGITAL Network Architecture (DNA) for the OpenVMS operating system.

DECnet-Plus integrates DECnet and OSI network protocols allowing both stacks to share integrated network functions up to the Transport layer. Upper layers have been implemented as separate "towers," allowing existing DECnet and OSI applications to share the integrated Transport layer. Existing DECnet Phase IV and new DECnet and OSI applications are supported by DECnet-Plus. In combination with TCP/IP protocol stacks, OpenVMS systems can participate in multivendor, multiprotocol networks adhering to Open Networking standards.

For details on specific upgrades and enhancements, refer to the DECnet-Plus for OpenVMS Release Notes.

Refer to Figure 2-1, which illustrates the integrated DNA Phase V Reference Model.

Figure 2-1 DNA Phase V DECnet-Plus for OpenVMS

DECnet-Plus for OpenVMS offers task-to-task communications, file management, and downline system and task loading. Network WAN connectivity is provided by WAN device drivers supporting host-based synchronous communications options for wide area networking.

DECnet-Plus for OpenVMS is available in two forms: End System and Extended Function. Extended Function provides all the features of End System plus the OSI application gateways (FTAM--DAP Gateway, VT-Telnet, LAT/VT and VT/LAT), the DECdns server (on VAX platforms), and host-based routing, and cluster alias.

The functions offered by OpenVMS are split into separate components. The entire base system installs automatically when you start the installation procedure, while the additional components are optionally installable. To support open, standards-based, multiprotocol communications, DECnet-Plus for OpenVMS is comprised of the DECnet-Plus base system (including DECdns and DECdts clerk software), and the following optional software:

• DECdts server---Software that synchronizes the system clocks in computers connected by a network.
• WAN device drivers---Software that links a hardware device and layered software for synchronous communications over wide area networks.
• X.25---Allows suitably configured DECnet-Plus systems to connect to Packet Switching Data Networks (PSDNs) conforming to CCITT recommendation X.25 (1980 or 1984) and/or to International Standards (ISO) 7776 and 8208. This allows a DECnet-Plus system to function as data terminal equipment (DTE) or be addressed as data circuit terminating equipment (DCE). On Alpha systems, X.25 is obtained separately from the DECnet-Plus software kit.
• Open System Application Kernel (OSAK) software---DIGITAL's implementation the OSI network architecture components that provide services for OSI applications.
• File Transfer, Access, and Management (FTAM) software---DIGITAL's OSI application that allows you to perform file operations between OSI-compliant systems.
  • DAP--FTAM gateway---Allows your DECnet-Plus node to participate in an OSI network in a simplified manner; for example, you can issue DCL commands to communicate with remote OSI systems through the gateway. Communication with a remote FTAM application is handled the same as any DECnet dialogue.
• Virtual Terminal (VT)---DIGITAL's OSI application that enables application and systems supporting different types of terminals to interoperate with each other. Using VT, you can use your terminal to access any other system running VT, regardless of the type of system. You can also use the VT gateways for access to and from non-OSI systems.
  • LAT/VT and VT/LAT gateways---Allows connections between a LAT terminal and OSI systems.
  • VT/Telnet and Telnet/VT gateways---Allows communications between OSI and Internet systems.

Table 2-1 lists the functions of DECnet-Plus for OpenVMS matched with the specific software components that you need to install and/or configure during the DECnet-Plus for OpenVMS installation procedure. Other dependencies are also noted.

The DECnet-Plus for OpenVMS base system software allows an OpenVMS system to perform as both a DECnet end node and an OSI end system. It can communicate using ISO 8802-3 (CSMA-CD) or ISO 8802-5 (FDDI) broadcast lines, either DIGITAL Data Communications Message Protocol (DDCMP) or point-to-point through HDLC lines.

The DECnet-Plus base software offers the following features:

1. End system implementation of the first four layers of the OSI Reference Model and all the layers of DNA
2. Host-based routing (that replaces DECnet Phase IV routing vector host-based environments not requiring high throughput)
3. Application, Presentation, and Session layers
   • File Transfer, Access, and Management (FTAM) application
   • Virtual Terminal (VT) application
   • Application Service Elements (ASEs), including ACSE (Association Control Service Element)
4. DNA Session Control layer (see Section 3.5)
   • Interprocess Communication ($IPC) programming interface
   • Queue Input/Output ($QIO) programming interface
   • Common Management Information Service Element (CMISE) programming interface
   • Support for DNA-based, DIGITAL and user applications
5. Transport layer, classes 0, 2, 4 (see Section 3.6)
   • OSI Transport Service
   • DIGITAL Network Services Protocol (NSP) Transport Service
   • RFC 1006 and RFC 1006 Extension (Internet Draft)
6. Lower layers
   • OSI addressing formats, supporting very large network topologies
   • End-system-to-intermediate-system (ES-IS) routing
   • Connectionless-mode Network Service (CLNS) over local area network (LAN), wide area network (WAN), and X.25
   • Logical link control type 2 (LLC2) for Connection-Oriented Network Service (CONS) over LAN
7. Network layer (see Section 3.7)
   • OSI-compliant addressing formats; virtually unlimited network size
   • ES-IS routing
   • CLNS which supports OSI Transport class 4 over ISO 8802-3 and X.25 connections
   • Internetwork Protocol to support CLNS
   • CONS which supports OSI Transport classes 0, 2, and 4 over ISO 8802-3 and X.25 connections
8. Data Link layer (see Section 3.8)
   • Supports High-level Data Link Control (HDLC) for wide area communications, ISO 8802-3 (Ethernet CSMA-CD) and FDDI LANs, and DIGITAL Data Communications Message Protocol (DDCMP) for backwards compatibility. HDLC support includes the Link Access Protocol Balanced (LAPB) protocol for X.25 communications.
   • ISO 8802-2 logical link control type 1 (LLC1)
   • FDDI driver support
9. Physical layer (see Section 3.9)
   • CSMA-CD, HDLC, and FDDI devices supported
10. Network management (see Section 3.10)
11. Network management support tools (see Section 2.8)
12. Node-name management support tools (see Section 2.8)

The DECnet over TCP/IP feature allows users to run standard DECnet applications in an Internet Protocol (IP) routing environment.

When you are running DECnet over TCP/IP, you can connect using an IP address, for example:

$ set host node.site.company.com

The connection is made using the DNA CTERM application instead of the TCP application FTP. Note that both the source and target nodes must support DECnet over TCP/IP for this connection to work. The system can be configured to allow you to use synonyms (Phase IV-style names) instead of the IP host full name. If a system does not run DECnet and support DECnet over TCP/IP, you need to use COPY/FTP to access that system. For example:

$ COPY/FTP myfile *

For more information on running DECnet over TCP/IP, refer to the DECnet-Plus Network Management and the installation and configuration guides. This feature requires any valid DECnet license and a licensed and installed TCP/IP product that supports the PATHWORKS Internet Protocol (PWIP) interface.

2.2.2 DIGITAL-Supplied Session Control Applications

A DECnet Phase IV "object" in DECnet-Plus is called an application. The DECnet-Plus for OpenVMS base system supplies the following session control applications, which are defined automatically at network startup:

• Task --- Image that provides full Phase-IV compatibility.
• File Access Listener (FAL) --- Image that provides authorized access to the file system of a DECnet-Plus system on behalf of processes executing on any network system. FAL communicates with the initiating system by means of the Data Access Protocol (DAP).
• CMIP Management Listener (CML) --- Image that allows remote management of the local system.
• Loopback mirror (MIRROR) --- Image used for some loopback testing.
• OpenVMS Mail --- Image that provides mail service for DECnet-Plus for OpenVMS systems.
• OpenVMS Phone --- Image that allows you to communicate with other users on your system or with any other connected DECnet-Plus system.
• OpenVMS Cluster Performance Monitor (VPM) Server --- Image used to run Open VMS Cluster monitoring features of the Monitor utility (MONITOR).

The DECnet-Plus for OpenVMS base system offers the following programming interfaces.

• Common Management Information Element Service (CMISE) interface
  DECnet-Plus for OpenVMS CMISE application programming interface provides the mechanism for user-written applications to perform OSI network management, and implements the ISO 9595 Common Management Information Service specification on OpenVMS. Two cooperating management applications in an OSI network are known as CMISE service users. These service users establish an association and exchange management information by means of the CMISE interface.
  The CMISE interface provides three types of management services:
  • Management Association Services for the establishment and release of associations between service users
  • Management Operation Services for the transfer of management information between service users
  • Management Notification Services for the reporting of events between service users
• Interprocess Communication ($IPC) interface
  DECnet-Plus for OpenVMS $IPC system service is an OpenVMS operating system interface to the Session Control layer that can be used to perform interprocess communication. This interface is a standard OpenVMS system service call.
  With the $IPC system service, distributed applications can run in a variety of environments without modification. $IPC operates over both local area and wide area connections. $IPC provides for efficient communication within a single DECnet-Plus for OpenVMS system, and between a DECnet-Plus for OpenVMS system and any other system running DECnet-Plus software in either a DECnet-Plus or multivendor network environment.
  $IPC provides basic connection, data transfer, and information management services. It permits an association to be opened between the application and the DNA Session Control layer. The $IPC interface can then create or accept connections over the opened association. $IPC can receive and process multiple inbound connection requests destined for a single application.
  Connection to the remote target can be made through specification of:
  • The DECdns object name of the target application, if your network uses the distributed DECdns namespace. For this connection, Session Control transparently selects the protocol tower information to be used based on the protocol and address information supplied by DECdns for the application service.
  • Protocol towers for the target application (as stored in the DNA$Towers attribute) that specify which address and protocol is to be used to communicate with the application.
  • A Phase IV or DECnet-Plus node name and application identification. (The target application can be identified by the internal version of a DECnet-Plus full name properly formatted for the Local namespace on DECdns or by a Phase IV object number or task name.)
  
  The primary functions of $IPC include:
  • Connection setup services --- Opens an association between an application and Session Control and declares an application name for incoming connections. (Also performs the function of shutting or closing associations.)
  • Connection services --- Requests a logical connection to a target task, identifying the target application in the connect initiate request.
  • Control services --- Receives incoming connect initiate requests, associates the requests with the calling process, and accepts or rejects the connection. (Also disconnects or aborts connections.)
  • Data transfer services --- Transmits and receives messages, including expedited data messages (messages that bypass flow control mechanisms). Receives unsolicited network events, such as third-party disconnects.
  • General services for managing information about the system and connections --- Resolves names, obtains information about a current connection, enumerates local towers, and supports backward translation of an address.
• Queue Input/Output ($QIO) interface
  DECnet-Plus for OpenVMS continues to support transparent and nontransparent task-to-task communications applications that use $QIO system service calls in the same way as for Phase IV. If a 6-character limit on node names is encoded in the Phase IV application, use a Phase IV-style node synonym for both incoming and outgoing connections.
  In addition, DECnet-Plus for OpenVMS supports $QIO calls that are specifically required for applications coded to the OSI Transport Service.
• Remote Access Interfaces
  With DECnet-Plus for OpenVMS, you can perform network operations as a natural extension of the input/output operations on the local system. In addition, a DECnet-Plus for OpenVMS programmer can write command procedures and programs that make the network transparent to users.
  You can access remote files and tasks using DCL commands and command procedures, higher-level language input/output statements, or OpenVMS Record Management Services (RMS). For example, programs written in COBOL, C, Ada, MACRO, Fortran, BASIC, Pascal, or PL/1 can access remote files.

A DECnet-Plus for OpenVMS system functions as an OSI end node if, during configuration, you configure OSI Transport. An application can set up a transport connection to another application on any other system, either DIGITAL or multivendor, running software that implements the OSI Transport Protocol.

2.2.5 NSP Transport Service

DECnet-Plus for OpenVMS software includes the Network Services Protocol (NSP) for DECnet Phase IV compatibility. You can use the proprietary NSP and the open OSI Transport Protocols simultaneously.

2.2.5.1 End-System-to-Intermediate-System (ES-IS) Routing

The ISO End-System-to-Intermediate-System (ES-IS) Routing Exchange Protocol provides the process by which end systems communicate with intermediate systems (routers), or with each other, to exchange configuration information.

You can configure a LAN with all end systems. In end-system-only configurations, the DECnet-Plus systems use ES-IS routing to communicate directly with each other. They use a specific multicast address to which all end systems listen. With this routing process, the concept of adjacency does not exist.

2.2.6 Network Management

DECnet-Plus network management offers the following benefits:

• Consistency across the DIGITAL Network Architecture (DNA), which in turn allows products developed by different sources to be managed in a consistent way.
• A modular design, which allows systems to be as simple or as complex as appropriate to the services they provide their users.
• Extendibility, which allows new functions to be added to DNA and managed consistently with existing functions.

You can perform the following network management functions:

• Controlling the network
• Providing host services to other DECnet-Plus systems
• Providing host services to DECnet Phase IV nodes
• Establishing DECnet-Plus configurations

Section 3.10 introduces the concepts of DECnet-Plus network management.

2.2.7 Name Service

The DECnet-Plus Session Control layer requires a name service to map node names to addresses. A DECnet-Plus network can use one namespace exclusively, or it can have a mixture of systems using the Local namespace, the DECdns distributed namespace, and/or DNS/BIND.

DECnet-Plus provides access to the node name and addressing information stored in one or more of the following name services:

• The Local namespace is a discrete, nondistributed namespace that stores name and address information locally in database files. It maintains a database of names and addresses on the local node. Use a Local namespace if you decide not to use a distributed namespace, or if you decide to delay full planning and implementation of a distributed namespace. The Local namespace is designed to scale up to at least 100,000 nodes depending on the number of address towers stored.
• The DIGITAL Distributed Name Service (DECdns) software is a distributed, global name service that allows users and applications to assign unique names to resources and then use these resources without knowing their physical location.
  With DECdns, each DECnet-Plus for OpenVMS system that does not use a Local namespace will be configured as a DECdns clerk. DECdns clerks request servers to provide address mapping for them. Because DECnet-Plus for OpenVMS does not contain DECdns server software, servers running on DIGITAL UNIX or OpenVMS systems must handle clerk requests.
  The DECnet-Plus for OpenVMS configuration procedure autoconfigures the DECdns clerk software.
• The Domain Name System (DNS/BIND) is the distributed name service for TCP/IP and supports the storage of IP addresses. In addition, support for DNS/BIND provides for the use of node synonyms. This allows for backward compatibility with older applications that cannot use long domain names.
  There are two ways to configure node synonyms for use with DNS/BIND:
  • By constructing an appropriate set of naming search path templates.
  • By defining local aliases.

While configuring DECnet-Plus, the system administrator specifies one or more of the following name services to use on the node: the Local namespace, DECdns, or Domain (for DNS/BIND).

DECnet-Plus includes a new in-memory naming cache to improve performance of name and address resolution for all supported name services.

DECnet-Plus includes features to ease namespace management including decnet_register (a namespace management tool), numerous NCL commands, and Common Trace Facility (CTF) support for monitoring node name and address resolution. In some instances, this simplified access to multiple name services is referred to as CDI or the common directory interface.

In addition to the Local namespace and DECdns, for node-name-to-address mapping your network can use, if it has one, an existing VAX Distributed Name Service (DNS) Version 1 namespace.