OpenVMS System Manager's Manual

21.2.1 DECnet-Plus Features

• Global name/directory services that allow large networks to easily store, manage, and access addressing information for (potentially) millions of network objects, such as end systems, users, printers, files, and disks.
• Optional local name/directory services for smaller networks that do not have as critical a need for global directory services.
• Expanded network management capabilities with the Network Control Language (NCL).
• An improved routing algorithm (link state routing) that provides a more efficient algorithm for passing routing information while keeping the overhead traffic to a minimum. Link state routing is only supported on dedicated routers.
• Host-based routing that allows an OpenVMS system to operate as a DECnet-Plus intermediate system in a routing domain. DECnet-Plus for OpenVMS host-based routing includes support for:
  • Communication with nodes running DECnet Phase IV and OSI protocols
  • Full cluster alias configuration
  • The DECnet Phase IV routing vector protocol (default)
  • FDDI large packets
  • Digital Data Communications Message Protocol (DDCMP) (supported on VAX only)
  • X.25 switched virtual (SVC) and permanent virtual circuits (PVCs) on VAX systems, and SVCs on Alpha systems
  
  This feature is especially useful for those configurations where you need to route from a LAN to a WAN and want to use an existing system to do the routing rather than investing in a dedicated router. Host-based routing is not intended for use in network configurations that have high-throughput requirements.
• Increased addressing capacity with the OSI standard address format, making possible unique addressing for virtually an unlimited number of nodes. Existing Phase IV addresses can continue to be used for systems upgraded to DECnet-Plus. The Phase IV address is automatically converted by the configuration procedure to the OSI address format (as a DECnet Phase IV compatible address).
• Address autoconfiguration that enables an adjacent adjacent router to configure the node address for the local node.
• Single configuration for OSI components.
  X.25 (on VAX systems), wide area device drivers (WANDD), File Transfer, Access, and Management (FTAM), and Virtual Terminal (VT) applications are included with DECnet-Plus software. (On Alpha systems, X.25 support is separate from DECnet-Plus software.)

To fully benefit from these new features, you may need to alter your present network. Section 21.2.4 reviews the decisions you must make prior to upgrading.

21.2.2 DECnet-Plus for OpenVMS Software Components

DECnet-Plus comprises a base system and optional components. The base system of components installs automatically when you start the installation procedure. Base system components include:

• OSI Transport Service classes 0, 2, 4
• TCP/IP stack
• Routing (ED-IS)
• Network Control Language (NCL)
• Enhance event logging (EVD) and the Common Trace Facility (CTF) (network management support tools)
• DECNET_REGISTER (node-name management support tool)
• DECdns clerk, DECdts clerk

The following components are optionally installable:

• DECdns server---Software that provides network applications a means of assigning unique names to network resources.
• 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 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 installed separately from the DECnet-Plus software kit.
• OSI Application Kernel (OSAK) software---Digital's implementation of the OSI network architecture components that provide services for OSI applications.
• 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.
• VT---Digital's OSI application that enables applications 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.
• 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.

To use DECnet-Plus for OpenVMS or DECnet Phase IV software, you need the appropriate software licenses. Table 21-3 lists the two basic licenses (end system and extended function) and three license keys for OpenVMS VAX and Alpha systems, for DECnet Phase IV and DECnet-Plus, respectively.

Table 21-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-Plus functionality except cluster alias, OSI API¹, OSI application gateways, DECdns server, and routing	All DECnet Phase IV functionality except cluster alias	All DECnet-Plus functionality except cluster alias, OSI API¹, OSI application gateways, and routing
Extended Function License
DVNETRTG	DVNETRTG	DVNETEXT	DVNETEXT
All DECnet Phase IV functionality including cluster alias² and routing	All DECnet-Plus functionality including cluster alias², OSI API, OSI application gateways, DECdns server, host-based routing³	All DECnet Phase IV functionality including cluster alias² but excluding routing 4	All DECnet-Plus functionality including cluster alias², OSI API, OSI application gateways, host-based routing³

21.2.4 Preparing to Join a Network

If your users on the DECnet-Plus network need the ability to communicate with users on other OSI networks, either through electronic mail, EDI, FTAM, VTP, or other internetwork utilities, you must obtain from an authorized authority such as ANSI, a unique network identifier called a new domain part (IDP). This is a part of the NSAP.

If your users do not need to communicate with others on OSI networks, a default IDP is provided with DECnet-Plus that you can use at configuration time. For more information on addressing, see DECnet-Plus Planning Guide.

21.2.4.2 Selecting a Name Service

For mapping between node names and node addresses, you need at least one of the three name services: Local namespace, DECdns, or 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, see the table below or 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.

Name Service	When to Use
Local Namespace	With small networks with no need to use a distributed namespace (name mapping is administered separately on each node.) Local namespace is similar to the permanent node database (NETNODE_REMOTE.DAT), used on DECnet Phase IV systems. To use the Local namespace, no additional software is required.
DECdns	With larger networks, with the need to administer and store node names from one location. Two or more servers running DECdns software are required. The DECdns server software is optional software included with the DECnet-Plus for OpenVMS software kit. For more information, see DECnet-Plus Planning Guide DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration DECnet-Plus DECdns Management
DNS/BIND	When running DECnet-Plus applications over TCP/IP. DNS/BIND supports the storage of IP addresses and the use of node synonyms that allow for backward compatibility with older applications that cannot use long domain names. DECnet-Plus requires one or more DNS/BIND servers in the network. See the appropriate TCP/IP documentation for more information on DNS/BIND.

21.2.4.3 Selecting DECdts Time Servers

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.

21.2.4.4 Setting Up Routers

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

21.2.4.5 X.25 Licenses and Dependencies

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). The right to use X.25 Native Mode software (formerly known as VAX P.S.I.) 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 DECnet-Plus for OpenVMS Introduction and User's Guide.

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 utilize any of the X.25 APIs or utilities over either LAN or WAN, an X.25 for OpenVMS Alpha systems license is required.

If you plan to use the DECnet over TCP/IP feature or the OSI over TCP/IP feature on OpenVMS systems, TCP/IP software is a prerequisite. The TCP/IP software used on your system must support the PATHWORKS Internet Protocol (PWIP) interface.

21.2.5 DECnet-Plus Node Names

Naming conventions for DECnet node names correspond to the two types of DECnet functionality:

• DECnet-Plus full names
  Full names are hierarchically structured DECnet node names that can be stored in a DECdns name service. Full names can be a maximum of 255 bytes long.
• DECnet Phase IV node names, called node synonyms in DECnet-Plus
  These names are the shorter names used by DECnet Phase IV, restricted to six characters or less. Using these names enables DECnet-Plus to be backward compatible with DECnet Phase IV systems in the same network.

Syntax for Full Names

Full names have the following general syntax:

namespace:.directory ...  .directory.node-name    

where:

namespace	Identifies the global name service
directory ... .directory	Defines the hierarchical directory path within the name service
node-name	Is the specific object defining the DECnet node

The following are examples of node full names for the Local namespace, DECdns, and DNS/BIND, respectively:

 Local namespace -  LOCAL:.CPlace 
 DECdns          -  ACME:.warren.CPlace 
 Domain          -  CPlace.warren.acme.com 

The system stores a full name as you enter it, preserving uppercase and lowercase entries. However, when matching an entry with a stored full name, the system is case insensitive; in other words, if the user enters Acme, the system recognizes it as equivalent to ACME.

For more information on full names, refer to the DECnet-Plus documentation.

21.2.6 Support for OpenVMS Cluster Systems

DECnet-Plus for OpenVMS software continues support for OpenVMS Cluster systems and the use of OpenVMS Cluster aliases. DECnet-Plus allows for three aliases for each OpenVMS Cluster. DECnet Phase IV nodes cannot be DECnet-Plus alias members. A separate alias must be configured for use with DECnet Phase IV nodes.

The CLUSTER_CONFIG.COM command procedure performs an OpenVMS Cluster configuration. It can configure all members of a cluster from any cluster member. It 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 configure an OpenVMS Cluster. Use NET$CONFIGURE.COM directly to configure additional DECnet-Plus satellite nodes once CLUSTER_CONFIG.COM has already been used.

21.2.7 Configuring DECnet-Plus

The NET$CONFIGURE.COM configuration procedure offers you three options for configuring DECnet-Plus. Table 21-4 reviews these options.

Table 21-4 DECnet-Plus Configuration Options

Option	When to Use
FAST	For quick configuration when: You want your DECnet-Plus (Phase V) system to operate in the same way as a DECnet Phase IV system. You are not completely familiar with the DECnet-Plus product and are upgrading a DECnet Phase IV node to DECnet-Plus. The DECnet-Plus system configures itself by determining the Phase IV and OpenVMS operating system parameters. The local namespace is used for naming information. You can reconfigure the system at a later time to include additional functionality. The FAST option is not supported on a node that is running in an OpenVMS Cluster or on a node that is a DECdns server.
BASIC	You plan to accept defaults for most components but want to customize a few, for example: Communications device or multiple communications devices used for DECnet-Plus communications Names for all devices and routing circuits Autoconfigure your network addresses For more information, see DECnet-Plus for OpenVMS Installation and Basic Configuration.
ADVANCED	For customizing your system's network configuration, such as to: Use DECnet-Plus over TCP/IP or OSI over TCP/IP Support multiple communications devices with a mix of protocols Add more flexibility in how you run X.25 services Specify your own names for certain network components rather than accepting the defaults Configure DECnet-Plus for OpenVMS VT, OSAK, and/or FTAM software Configure your system as a DECdns server Configure your own NETs rather than have them autoconfigured For more information, see DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration.

You can also use NET$CONFIGURE.COM to reconfigure all or individual entities of the local DECnet-Plus for OpenVMS system. Rerunning the configuration procedure modifies or replaces relevant initialization script files but does not affect running systems. You then execute the modified initialization script files to effect these changes.

The initialization scripts create and enable all required entities. Each entity is initialized through execution of a separate NCL script file. Using NCL scripts to initialize DECnet-Plus for OpenVMS systems replaces the Phase IV requirement of establishing a DECnet permanent configuration database at each node. Remote node information resides in either a local or distributed namespace (DECdns or DNS/BIND).

For further information, refer to the DECnet-Plus Network Management guide.

21.2.8 Moving Your Phase IV Network to DECnet-Plus

If you are involved in transitioning your network from DECnet Phase IV to DECnet-Plus, you may choose to move portions of a network, or the entire network, from DECnet Phase IV to DECnet-Plus. Remember that DECnet-Plus is backward compatible, meaning that you can choose to run your system and the network in the same manner as you have before, using DECnet Phase IV applications, routing, and so forth. You can implement the additional functionality available to you from DECnet-Plus any time you are ready. The changes mostly involve network management. They are almost entirely transparent to users and applications.

A number of automated tools (DECnet transition utilities and the NCP Emulator) are available, in addition to the simplified configuration procedures, to help ease the transition to full DECnet-Plus functionality.

The DECnet-Plus Planning Guide details steps for transitioning your network.

21.2.9 Network Management Tools

DECnet-Plus for OpenVMS provides network tools that let you:

• Manage local and remote DECnet Phase V components. Two interfaces are available: the the Network Control Language (NCL) command-line interface and a Motif-based windows interface (NET$MGMT.)
  Digital supplies the DECNET_MIGRATE tool that converts individual DECnet Phase IV NCP commands to NCL commands, and NCP commands within command procedures to NCL commands. You can use DECNET_MIGRATE when you are new to DECnet-Plus, learning NCL, and want help specifying familiar NCP commands in NCL syntax.
• Manage remote DECnet Phase IV nodes with the NCP Emulator (NCP.EXE). This utility supports a significant range of NCP commands. It is not designed to replace NCL for managing a DECnet-Plus system.
• Use DECnet-Plus for OpenVMS initialization scripts (files in the form SYS$MANAGER:NET$*.NCL).
• Perform maintenance operations (using MOP) such as downline load, upline dump, remote console connection, and loopback testing support. DECnet-Plus for OpenVMS provides enhanced support and performance for concurrent downline loads. For more information on MOP and how to start this process, see the DECnet-Plus for OpenVMS Network Management guide.
• Perform enhanced event logging using EVD.
• Use Common Trace Facility (CTF) for troubleshooting.
• Use the DECNET_REGISTER tool to assist in managing node names in your network for the Local and DECdns namespaces.

The primary network management tasks include the following:

• Providing security for the node
• Managing namespace information
• Monitoring network activity
• Customizing the network configuration
• Shutting down and restarting the network

The following sections briefly describe these tasks. Refer to the DECnet-Plus for OpenVMS Introduction and User's Guide for instructions on using management tools and the DECnet-Plus for OpenVMS Network Management guide for complete information on maintaining, controlling, shutting down, and restarting the network. The DECnet-Plus Problem Solving guide includes information for testing and troubleshooting.

21.2.10.1 Providing Security for Your Node

DECnet-Plus regulates access to the network on various levels, including the following:

• Rights identifiers for access to the network
• Access control
• Routing initialization passwords for connecting local nodes to remote nodes

The following sections describe these levels of control.

Required Rights Identifiers

DECnet-Plus for OpenVMS uses OpenVMS rights identifiers to perform access checks on all manageable entities. This differs from the Phase IV software, which used OpenVMS privileges for access to the permanent database and for write access. Read access to the volatile database in Phase IV was unprotected.

In DECnet-Plus for OpenVMS, three rights identifiers allow the network manager to restrict access to network parameters. Access is granted to an individual user by means of the Authorize utility AUTHORIZE on OpenVMS. These are used as follows:

Rights Identifier	Access Granted
NET$EXAMINE	Read access to the network configuration data. For example: UAF> grant/id net$examine Joe
NET$MANAGE	Read and write access to the network configuration data. For example: UAF> grant/id net$manage Joe
NET$SECURITY	Ability to set default accounts. For example: UAF> grant/id net$security Joe

In lieu of NET$MANAGE rights, the BYPASS privilege will grant read and write access.

Access Control

Whenever a DECnet node attempts to connect to a remote DECnet-Plus node, it sends access control information to the Session Control entity on the remote node. Access control allows you to control connections between nodes. Access control information can come from a number of sources. The following list shows the hierarchy of access control from highest to lowest priority. See the DECnet-Plus for OpenVMS Network Management guide for details.

1. The network user on the local node can explicitly supply access control information, such as in the following example:

   $ MCR NCL SHOW NODE CPLACE"NOWAK QUICKONE" ALL 
   

   
   In this case, the remote node uses the access control information.
2. If no explicit access control information has been provided, the local node checks to see if outgoing proxy access is enabled for a local node or an application. If the proxy is enabled, the local node initiates a connection and the Session Control entity on the remote node determines if the initiating user has proxy access.
3. When the remote node sees that no explicit access control has been specified and that no proxy matches, it checks its application database. If the database contains an application user name, it uses that name.
4. If no default application user name exists in its application database, the remote node checks its Session Control entity attributes for default nonprivileged DECnet user name information. If the information is there, the remote node uses the default nonprivileged DECnet user name.
   The default DECnet user name allows users to perform certain network operations, such as the exchange of electronic mail between users on different nodes, without having to supply a user name and password. The default DECnet user name is also used for file operations when access control information is not supplied. For example, it permits remote users to access local files on which the file protection has been set to allow world access. If you do not want remote users accessing your node, do not create a default DECnet user name.

Finally, if none of these sources supply valid access control information, the connection fails.

Note

In DECnet-Plus, "nonprivileged" means having NET$DECNETACCESS rights and TMPMBX and NETMBX privileges. These are the minimal rights and privileges necessary for any network activity. "Privileged" means any rights and privileges in addition to NET$DECNETACCESS rights and TMPMBX and NETMBX privileges.

---

Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

---

  6017P064.HTM
  OSSG Documentation
  22-NOV-1996 14:22:51.11

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal