Document revision date: 30 March 2001

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 or fewer characters. 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 examples show 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 about full names, refer to the DECnet-Plus documentation.

23.8.2 Support for OpenVMS Cluster Systems

DECnet-Plus software supports OpenVMS Cluster systems and the use of 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.

23.8.3 DECnet-Plus Management Tools and Utilities

DECnet-Plus for OpenVMS provides a variety of network tools that let you perform the following tasks:

• Manage local and remote DECnet Phase V components. Two interfaces are available: the Network Control Language (NCL) command-line interface and a Motif-based windows interface (NET$MGMT.)
  Compaq 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 about MOP and how to start this process, refer to 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.

Before configuring your DECnet-Plus node, you must make some decisions regarding addressing, the use of name services, time services, and routers. You must also be aware of license dependencies unique to X.25 software.

For detailed planning information, refer to the DECnet-Plus Planning Guide.

23.10 Installing and Configuring DECnet-Plus

You can install DECnet-Plus for OpenVMS software on your system in either of the following ways:

• From the OpenVMS installation procedure menu, as part of the operating system upgrade or installation
• As a layered application using the DCL command PRODUCT INSTALL

Once the DECnet-Plus software is installed successfully, you invoke a menu-based configuration procedure to configure the software according to the unique characteristics of your system and network:

• Use the Fast configuration option if you are upgrading from a DECnet Phase IV node, you plan to use the existing Phase IV configuration, and your node is not part of an OpenVMS Cluster. Enter:

  $ @SYS$MANAGER:NET$CONFIGURE

• Use the Basic configuration option if your node is in a cluster, you are upgrading or reconfiguring DECnet-Plus, and you want to run DECnet over TCP/IP. Enter:

  $ @SYS$MANAGER:NET$CONFIGURE BASIC

• Use the Advanced configuration option if your node's configuration is complex and you need to customize it. Enter:

  $ @SYS$MANAGER:NET$CONFIGURE ADVANCED

For detailed installation and configuration information, refer to the DECnet-Plus for OpenVMS Installation and Basic Configuration manual.

23.11 Using DECnet Over TCP/IP

The DECnet over TCP/IP feature extends the DECnet Phase V architecture to coexist and communicate with TCP/IP networks. This feature requires a valid DECnet license and a licensed and installed TCP/IP product that supports the PATHWORKS Internet Protocol (PWIP) interface.

You should consider enabling DECnet over TCP/IP for the following purposes:

• Transition from DECnet to TCP/IP. To move to TCP/IP-based networks gradually based on business need. DECnet over TCP/IP functionality is designed to be transparent to users.
• Coexistence. To run DECnet or OSI applications, or both, in a TCP/IP-based network.

With DECnet over TCP/IP, you can:

• Expand your DECnet network to communicate over TCP/IP network backbones. DECnet over TCP/IP allows combinations of naming services (DECdns, large LOCAL file, and DNS/BIND).
• Expand the network by joining two existing DECnet networks without the need to renumber the nodes.
• Use IP-only traffic in part or all of the backbone. With DECnet over TCP/IP, DECnet or OSI applications can run over the lower levels of the TCP/IP protocol stack and the IP network backbone.
• Enable the feature on a node-to-node basis or throughout the entire network.

The DECnet over TCP/IP functionality uses TCP/IP to form a logical link between DECnet nodes. It uses the PATHWORKS IP Driver to interface with TCP. DECnet applications run transparently between DECnet nodes connected by TCP/IP. Users on those DECnet nodes can connect to each other using DECnet node synonyms or IP fullnames. For example:

$ SET HOST SYSABC $ SET HOST SYSABC.boston.acme.com $ SET HOST 16.12.42.19

To enable DECnet over TCP/IP on your system, you must do the following primary tasks:

• Install and configure DECnet-Plus on the system.
  When you run the NET$CONFIGURE procedure, specify the Domain directory service (for TCP/IP addresses) as well as the Local or DNS/BIND service when prompted by the configuration procedure.
• Install and configure TCP/IP Services on the system.
  When you run the TCPIP$CONFIG configuration procedure, enable the PWIP driver to form a bridge between DECnet-Plus and TCP/IP Services software. The PWIP driver is listed as Option 1 on the Optional Components menu.

For detailed information about enabling and using DECnet over TCP/IP, refer to the DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration and DECnet-Plus for OpenVMS Network Management manuals.

23.12 Moving Your DECnet Phase IV Network to DECnet-Plus

If you are planning to transition your network from DECnet Phase IV to DECnet-Plus, you can move portions of the network to DECnet-Plus or move the entire network. Because DECnet-Plus is backward compatible, 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.

For detailed information about transitioning your network, refer to the DECnet-Plus Planning Guide manual.

23.13 Starting and Stopping DECnet-Plus

If you install DECnet-Plus from the OpenVMS installation menu, the software starts automatically. If you need to restart DECnet-Plus for any reason (for example, after shutting down the network by executing SYS$STARTUP:NET$SHUTDOWN.COM), enter the following command:

$ @SYS$STARTUP:NET$STARTUP

To shut down DECnet-Plus software, which disables and deletes various network entities on your system, enter:

$ @SYS$MANAGER:NET$SHUTDOWN

23.14 DECnet-Plus Documentation

Table 23-4 lists the documentation that supports the DECnet-Plus for OpenVMS software. For complete information about how to plan for, install, configure, and manage DECnet-Plus, refer to these documents.

Table 23-4 DECnet-Plus for OpenVMS Documentation

Manual	Contents
DECnet-Plus for OpenVMS Release Notes	Describes changes to the software; installation, upgrade, and compatibility information; new and existing software problems and restrictions; and software and documentation corrections. You can print this text file from the configuration procedure.
DECnet-Plus for OpenVMS Introduction and User's Guide	Provides an introduction to networking on the system and includes user information.
DECnet-Plus for OpenVMS Installation and Basic Configuration	Explains how to install DECnet-Plus and perform the BASIC configuration option.
DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration	Explains how to install and configure network applications and perform the ADVANCED configuration procedure option.
DECnet-Plus for OpenVMS Installation Quick Reference Card	Provides a quick reference for upgrading your system to DECnet-Plus during installation.
DECnet-Plus Planning Guide	Provides steps for transitioning from DECnet Phase IV functionality to DECnet Phase V.
DECnet-Plus for OpenVMS Network Management Quick Reference Guide	Provides a quick reference for DECnet-Plus network management.
DECnet-Plus for OpenVMS Network Management	Includes network management concepts and tasks for DECnet-Plus systems.
DECnet-Plus Network Control Language Reference	Provides command descriptions and examples for all NCL commands.
DECnet-Plus Problem Solving	Explains how to isolate and solve DECnet-Plus problems that can occur while the network is running, and how to perform loopback tests.

This chapter describes how the LAN software works and the tasks you must perform to manage the LAN software on your system.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Running the LANACP LAN server process	Section 24.3.1
Invoking and running LANCP	Section 24.4.1
Managing LAN devices	Section 24.5
Managing the LAN device databases	Section 24.6
Managing the LAN node databases	Section 24.7
Migrating from DECnet MOP to LAN MOP	Section 24.8.2
Using CLUSTER_CONFIG_LAN.COM and LAN MOP	Section 24.8.3
Managing the MOP downline load services	Section 24.9
Initiating the MOP console carrier	Section 24.9.8
Requesting MOP trigger boot	Section 24.9.9

This chapter explains the following concepts:

Concept	Section
Local area networks	Section 24.1
LANACP LAN server process	Section 24.3
LANCP utility	Section 24.4
MOP downline load services	Section 24.8

24.1 Understanding Local Area Networks

A local area network (LAN) provides a communications channel designed to connect information processing equipment in a limited area such as a room, a building, or a complex of buildings (for example, a campus). Nodes in a LAN can be linked by the following types of data transmission media:

• Ethernet---One of the earliest and the most common LANs. Ethernet can refer to either a general LAN application (for example, Ethernet address) or to the specific CSMA/CD (carrier sense multiple access with collision detection) technology that implements the Intel, Xerox, and Compaq intercompany Ethernet specifications.
  There are three types of Ethernet LANs as follows:
  • Ethernet (802.3) with transmission speeds of 10Mbps
  • Fast Ethernet (802.3u) with transmission speeds of 100Mbps
  • Gigabit Ethernet (802.3z) with transmission speeds of 1000Mbps
  
  All three types of Ethernet employ CSMA/CD protocol, and the same frame format and same frame size.
• FDDI (Fiber Distributed Data Interface) --- Implemented as dual-ring, token ring LANs.
• Token Ring---The IEEE 802.5 standard token passing ring.
• ATM (Asynchronous Transfer Mode) --- The following standard is supported:
  • LAN emulation over ATM supports the ATM Forum's LAN Emulation V1.0 (LANE) standard.
  • Classical IP over ATM supports the RFC 1577 standard. (DGLTA, DGLPA, DGLPB only)

LAN controllers are devices that, along with additional external hardware, implement the Ethernet, FDDI, Token Ring, LAN emulation over ATM or Classical IP (RFC 1577) specifications. A LAN controller and the local system constitute a node. The LAN controller communicates with the local system through the system bus, and with remote systems implementing the Ethernet, FDDI, Token Ring, or LAN emulation over ATM specifications through the communication medium. (The Ethernet specification is described in The Ethernet--Data Link Layer and Physical Layer Specification. The FDDI specifications are available from ANSI. The Token Ring specifications are available from IEEE. The LAN emulation over ATM specifications are available from the ATM Forum.)

Application programs use the LAN driver's QIO interface to perform I/O operations to and from other nodes on the LAN. For detailed information about the QIO interface, refer to the OpenVMS I/O User's Reference Manual.

Table 24-1 provides a brief summary of the differences between the types of LAN media.

Table 24-1 Characteristics of LAN Media

Media	Speed	Maximum Frame Size	Maximum Cable Lengths+
Ethernet 802.3	10Mbps	1518 bytes	100 meters
Fast Ethernet 802.3u	100Mbps	1518 bytes	100Base-TX---100 meters 100Base-FX---412 meters (one-half duplex) -- 2000 meters (full-duplex)
Gigabit Ethernet 802.3z	1000Mbps	1518 or 9018 bytes	1000Base-SX fiber optic -- 550 meters 1000Base-LX fiber optic---5 kilometers 1000Base-CX copper shielded---25 meters 1000BaseT copper UTP---100 meters
FDDI	100Mbps	4495 bytes	40 kilometers
Token Ring 802.5	4 or 16 Mbps	4462 bytes	300 meters
LAN emulation over ATM	155Mbps or 622Mbps	1516, 4544, or 9234	2 kilometers, 300 meters

An Ethernet is a cable to which each system or device is connected by a single line. In an office or other area where personal computers and workstations are located, ThinWire Ethernet or unshielded twisted-pair cabling is usually used.

Individual systems can either be connected directly to an Ethernet or gain access to an Ethernet by means of a local area interconnect device, such as a DELNI. A DELNI serves as a concentrator, grouping systems together. Many similar devices, such as hubs, repeaters, and switches also provide the connectivity.

24.1.1.2 FDDI LANs

FDDI uses a dual ring of trees topology. It uses one ring as the primary ring, the other ring as a backup, and the tree configuration for increased flexibility, manageability, and availability.

FDDI networks and Ethernet networks can be combined to form a single extended LAN. This lets applications running on a system connected to FDDI communicate with applications that run on a system connected to Ethernet.

An FDDI concentrator provides for the attachment of FDDI devices such as VAX and Alpha nodes or FDDI-Ethernet bridges to the FDDI LAN.

24.1.1.3 Token Ring LANs (Alpha Only)

Token Ring controllers use either shielded or unshielded twisted pairs of wire to access the ring. Note that it is difficult to connect a Token Ring LAN directly bridged to any other type of LAN. However, routing protocols to other LANs work easily.

24.1.1.4 ATM LANs (Alpha Only)

LANs over ATM consist of a connection-oriented network based on cell switching. The OpenVMS ATM network uses AAL5 ATM adaption layer for data transmission.

For LAN emulation over ATM, OpenVMS implements only the LAN emulation client (LEC) and does not implement the LAN emulation server (LES), the Broadcast and Unknown (BUS), or the LAN emulation Configuration Server (LECS). The LES, BUS, and LECS must be provided by some other facility such as the ATM switch. OpenVMS supports eight LAN emulation clients per ATM adapter.

Classical IP over ATM (CLIP) implements a data-link level device that has the same semantics as an Ethernet interface (802.3). This interface is used by a TCP/IP protocol to transmit 802.3 (IEEE Ethernet) frames over an ATM network. The model that OpenVMS follows for exchanging IP datagrams over ATM is based on RFC1577 (Classical IP over ATM).

24.1.2 LAN Addresses

Nodes on the LAN are identified by unique addresses. A message can be sent to one, several, or all nodes on the LAN simultaneously, depending on the address used.

Upon application, IEEE assigns a block of addresses to a producer of LAN nodes. Thus, every manufacturer has a unique set of addresses to use. Normally, one address out of the assigned block of physical addresses is permanently associated with each controller (usually in read-only memory). This address is known as the hardware address of the controller. Each controller has a unique hardware address.

A LAN address is 48 bits in length. LAN addresses are represented as six pairs of hexadecimal digits (six bytes) separated by hyphens (for example, AA-01-23-45-67-FF). The bytes are displayed from left to right in the order in which they are transmitted; bits within each byte are transmitted from right to left. In this example, byte AA is transmitted first; byte FF is transmitted last.

A LAN address can be a physical address of a single node or a multicast address, depending on the value of the low-order bit of the first byte of the address (this bit is transmitted first). The two types of node addresses are:

• Physical address---The unique address of a single node on a LAN. The least significant bit of the first byte of a physical address is 0. (For example, in physical address AA-00-03-00-FC-00, byte AA in binary is 1010 1010, and the value of the low-order bit is 0.)
• Multicast address---A multidestination address of one or more nodes on a given LAN. The least significant bit of the first byte of a multicast address is 1. (For example, in the multicast address 0B-22-22-22-22-22, byte 0B in binary is 0000 1011, and the value of the low-order bit is 1.)
  Token Ring devices do not support IEEE 802 standard multicast addresses. They do support functional addresses. A functional address is a locally administered group address that has 31 possible values. Each functional address sets one bit in the third through sixth bytes of the address, and bytes 1 and 2 are 03-00 (C0:00 in bit reversed format). To convert a multicast address to a functional address, use the SET DEVICE/MAP command.

	privacy and legal statement
6017PRO_093.HTML