HP OpenVMS Systems Documentation

Content starts here

DECnet-Plus for OpenVMS
Introduction and User's Guide

Previous Contents Index

3.10.2 How the Director Works

The Network Control Language (NCL) is a command line interface to the director, which interprets the input NCL commands, sends these commands to a target entity for processing, and presents the results back to the network manager.

Directors use common mechanisms to communicate with the entities they manage. The same director can manage both local and remote entities. If the managed entity resides on the local system, the director uses the local interface to access it. If the managed entity resides on a remote system, the director converts the NCL message to CMIP and sends the converted message to the entity agent on the remote system.

The management information and operations that pass between directors and entities are:

  • Directives --- The management commands issued by a director to an entity. They allow a director to read and alter an entity's management attributes, or to request it to perform a specific action.
  • Attributes --- A piece of management information maintained by an entity. Each attribute has a name allowing it to be accessed by management. The four types of attributes are:
    • Identification: identifies an entity to network management.
    • Characteristics: allows control of the operating parameters of an entity. In general, characteristic attributes take default values when the entity is created, but you can change them with NCL commands.
    • Status: allows you to inspect the current state of an entity. Unlike characteristic attributes, status attributes can change without management intervention.
    • Counters: values that indicate the number of times an operation has been performed by an entity or a particular condition has been detected.
  • Events --- an occurrence of a specific normal or abnormal condition. Management Access Relationship

The management access relationship between a parent entity and a child entity indicates that the parent is capable of passing directives to its child entities. A parent entity is an entity that has created another entity (the child entity); a child entity is a lower class of entity that receives directives forwarded from its parent entity.

The DECnet-Plus director does not directly access the agents of local entities. To access a local entity's management interface, the director accesses the appropriate global node entity that is the parent of the target local entity. That node entity forwards the directive down the entity hierarchy; the forwarding process continues from higher to lower entities until the correct target entity receives the directive. The agent access point is the place of connection between a director or a parent entity and an agent. Management of Remote DECnet Phase IV Nodes

The DECnet-Plus network management protocol is based on DNA Common Management Information Protocol (DNA CMIP) draft standard for network management operations. CMIP is used for encoding network management operations that can be performed on an entity. CMIP permits the exchange of information between a director and an agent. CMIP supersedes the Phase IV Network Information and Control Exchange (NICE) protocol.

DECnet-Plus software supports remote management of Phase IV nodes by continuing to support Phase IV NCP and the Phase IV network management protocol (NICE).

However, Phase IV applications that have been written to create logical links to the Phase IV Network Management Listener (NML) and then parse the returned NICE protocol messages are not supported for managing DECnet-Plus for OpenVMS systems. To run on a network composed of DECnet-Plus systems, those applications must be rewritten to use DECnet-Plus network management software and protocols. For example, the application may be rewritten to use the DECnet-Plus CML callable interface into network management. Also, Phase IV applications that use NCP to configure the application need to be converted to use NCL. Support for Phase IV NCP and the NICE Protocol

DECnet-Plus software supports remote management of DECnet Phase IV nodes by use of NCP.EXE. This utility supports a significant range of NCP commands. It is not designed as a replacement for NCL. Maintenance Operation Protocol (MOP) Support

With the Maintenance Operation Protocol (MOP), you can communicate with systems that are not fully operational, for example DECnet-Plus intermediate systems. Low-level maintenance functions of MOP run directly on top of data links, such as ISO 8802-2. MOP functions are often placed in ROMs on link controllers. MOP operations include:

  • Downline load and upline dump
  • Connection to remote consoles
  • Loopback testing

DECnet-Plus for OpenVMS provides enhanced support for concurrent downline loads.

3.10.3 Configuration Procedure for DECnet-Plus for OpenVMS

The net$configure.com configuration procedure offers you several options for configuring DECnet-Plus:

  • The FAST configuration option allows you to configure DECnet-Plus quickly, with a minimal number of questions. This new option is especially useful when you want your DECnet-Plus (Phase V) system to operate in the same way as a DECnet Phase IV system. Use this option when you are not completely familiar with the DECnet-Plus product and are upgrading a DECnet Phase IV node to DECnet-Plus. With the fast configuration option, you can quickly and easily configure a DECnet-Plus system with full network connectivity. The DECnet-Plus system configures itself by determining the Phase IV and OpenVMS operating system parameters. A local database holds naming information. You can reconfigure the system at a later time to include additional functionality.
    Currently, the fast configuration option is not supported on a node that is running in an OpenVMS cluster or on a node that is a DECdns server.
    You invoke the fast configuration feature by specifying the following command:

    $ @sys$manager:net$configure
  • The Basic configuration option (DECnet-Plus for OpenVMS Installation and Basic Configuration) allows you to configure your system for DECnet-Plus by answering a few questions and using the default answers on others. For example, use the Basic configuration option if you want to:
    • Configure one communications device, or multiple communications devices used for DECnet-Plus communications
    • Configure default names for all devices and routing circuits
    • Autoconfigure your network addresses
    You invoke the Basic configuration option by specifying the following command:

    $ @sys$manager:net$configure basic
  • The Advanced configuration option (DECnet-Plus for OpenVMS Applications Installation and Advanced Configuration) allows you to customize your system's network configuration, such as to:
    • Use DECnet 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 Virtual Terminal, OSAK, and/or FTAM software
    • Configure your system as a DECdns server
    • Configure your own network addresses (NETs) rather than have them autoconfigured

    You invoke the Advanced configuration option by specifying the following command:

    $ @sys$manager:net$configure advanced

You can also use net$configure.com to reconfigure all or some of the 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 DECdns namespace.

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

Chapter 4
X.25 Networking Concepts

4.1 Introduction

This chapter introduces basic X.25 networking concepts and how they fit into the DECnet standards for system interconnection as illustrated in Figure 2-2. Refer to the X.25 for OpenVMS Management Guide for specific information on managing and monitoring an X.25 system as well as descriptions of specific parts of an X.25 system (call handling, templates, application filters, server and relay clients, and addressing).

X.25 is a recommendation made by the Comité Consultatif International Téléphonique et Télégraphique (CCITT). The CCITT is a United Nations committee that makes recommendations on data communications services. The CCITT has made several recommendations to ensure that different networks are compatible in their operation. Many of its recommendations have been implemented widely by major network providers.

The X.25 recommendation specifies the interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for equipment operating in the packet mode on public data networks.

4.1.1 Packet Switching Data Networks (PSDN)

Packet switching is a method of sending data across a network. In this method, data is divided into blocks, called packets, which are then sent across a network. Networks using this method are referred to as packet switching data networks (PSDNs) or X.25 networks.

Figure 4-1 shows an example of the equipment involved in sending data across a PSDN. PSDNs are made up of packet switching exchanges (PSEs), and high-speed links that connect the PSEs. Each PSE contains data circuit-terminating equipment (DCE). The DCE is the point where all data enters and leaves a PSDN.

The user's computer that sends data to the DCE, and receives data from the DCE, is known as the data terminal equipment (DTE). Outside a PSDN, packets travel between the DTE and DCE. Inside a PSDN, packets travel between PSEs.

Figure 4-1 Packet Switching Equipment

A PSDN is either owned by a country's Postal, Telegraph, and Telephone (PTT), Authority or it is privately run. Public PSDNs can be used by anyone, on payment of connection fees and regular bills. Private PSDNs are used to serve a single body, such as a large corporation.

Public and private PSDNs can be interconnected. It is, therefore, possible to pass data packets from one DTE to another no matter where in the world the DTEs are located.

The PSDN sends each packet to its destination by the best available route at the time. The packets that make up a data message may take different routes to reach the same destination; this will occur if certain routes are busy or if there is a line failure within the PSDN. Figure 4-2 shows an example of packets traveling by different routes across a PSDN.

When the packets reach their destination, they are reassembled so that the original order of the packets in the data message is maintained.

Figure 4-2 Packets Traveling Over a PSDN

There are two types of data terminal equipment:

  • Packet-mode DTEs
    These DTEs communicate directly with PSDNs using X.25 packets; for example, a computer system.
  • Character-mode DTEs
    These DTEs cannot assemble or disassemble packets and have no X.25 communication capability. An example of a character-mode DTE is an asynchronous terminal. Character-mode DTEs communicate with a PSDN through a device known as a packet assembler/disassembler (PAD). Character-mode DTEs are often referred to as X.29 terminals.

4.1.2 PADs and Character-Mode Terminals

PADs allow character-mode DTEs to access PSDNs. A PAD performs the following functions:

  • Assembles a terminal's outgoing characters into packets for transmission across a PSDN, and disassembling incoming packets (that is, packets arriving from a PSDN) into individual characters.
  • Controls the transmission and receipt of packets.
  • Sets up virtual circuits.

There are three types of PAD:

  • Dial-in PADs provided by PSDNs for public use. This type of PAD allows users to dial in to a PSDN via a modem and from that PSDN access other DTEs. PAD functionality is provided by software in the PAD.
  • PADs that allow the connection of character-mode terminals to a PSDN without the need to dial in via a modem. These PADs are typically one separate, dedicated piece of hardware to which both the character-mode terminals and the PSDN are connected. This type of PAD allows multiple character-mode terminals to be connected to the PSDN. PAD functionality is provided by software in the PAD.
  • Host-based PADs, where the PAD functionality is implemented solely in the software installed on the host.

Figure 4-3 shows the following PADs:

  • DTE A is connected to the PSDN via a modem.
  • DTEs B and C are connected to the PSDN via a dedicated PAD.
  • DTE D is connected to the PSDN through its own, host-based PAD.
  • DTE E is a packet-mode DTE, which can connect directly to the PSDN without a PAD.

Figure 4-3 Connecting Character-Mode DTEs to a PSDN

4.2 X.25 Protocols

A protocol is a set of rules for the formatting and sequencing of data. X.25 describes three protocol levels for the interface between a DTE and a DCE:

  • Packet level
  • Frame level
  • Physical level

Figure 4-4 shows the three protocol levels.

Figure 4-4 X.25 Protocol Levels

At the sending DTE, data passes down through the levels and each level adds its own control information. When it reaches the physical level, the data is transmitted to the DCE.

At the DCE, the relevant control information is removed as the data passes up through the levels. When it reaches the packet level, data is in the form of X.25 packets, which can now be sent across a PSDN.

When the packets reach the remote DCE, they pass down through the levels and pick up control information. The DCE then sends them to the receiving DTE. At the receiving DTE, the data passes up through the levels.

Each level on the DTE communicates with the corresponding level on the DCE by using the same protocols; therefore, there are logical connections between corresponding levels. They are referred to as logical connections because data is not actually transmitted until it reaches the physical level.

Two DTEs implementing X.25 protocols can exchange data in packets, regardless of the DTE manufacturer. However, once the data is re-assembled in its original format, the receiving DTE may not be able to interpret the message. In this case, additional software may be required to make the data meaningful to the receiving DTE.

4.2.1 Packet Level

This level defines the procedures for formatting packets, sequencing packets, and establishing virtual circuits. Virtual circuits are the logical connections between two DTEs (see Section Most packets contain user data, but some are for control purposes. Control packets are used for functions such as initiating and terminating virtual circuits between two DTEs and for interrupt messages.

The amount of user data allowed in a packet is known as the packet size. The maximum amount of user data allowed in a packet is set by the PSDN you use. A typical packet size is 128 bytes.

Each packet (refer to Figure 4-5) consists of a packet header followed by user data or control information.

  • The packet header contains a logical channel number (LCN), and a packet type identifier. The LCN identifies the virtual circuit between the calling DTE and the called DTE (see Section 4.4.2). The packet type identifier labels the packet as containing either user data packet or control information.
  • The remainder of each packet contains either user data or control information.

Figure 4-5 Structure of a Packet

4.2.2 Frame Level

This level initiates communications between the DTE and the DCE and ensures that data is transferred between DTE and DCE without errors.

At this level each packet is enclosed within a frame. Each frame consists of:

  • Flags that indicate the start and end of the frame.
  • A frame header, which indicates whether the frame contains user data or control information.
  • A packet from the packet level (provided that the frame does not contain control information).
  • A 16-bit frame check sequence (FCS), which is used to determine whether the whole frame has been received without error after transmission.

Figure 4-6 shows the structure of a typical frame.

Figure 4-6 Structure of a Frame

4.2.3 Physical Level

This level defines the mechanical and electrical connections between a DTE and a DCE. It specifies electrical characteristics, data transmission speeds, and connector types.

4.3 Implemented Standards

X.25 is a CCITT recommendation that describes a standard for connecting to packet switching networks. The lower three layers of the OSI Reference Model correspond to the three levels in the Comité Consultatif International Téléphonique et Télégraphique (CCITT) X.25 recommendation.

The X.25 standard describes the protocols for the DTE-DCE interface.

4.3.1 Related CCITT Standards

The X.25 recommendation describes only those protocols involved in the DTE-DCE interface to packet switching networks. There are several other CCITT recommendations that are relevant to packet switching, including:

  • X.3 --- Defines the service provided to the terminal by the PAD. The service is described in terms of PAD parameters.
  • X.28 --- Defines the user interface to the PAD.
  • X.29 --- Defines the procedure for the exchange of control information and user data between a PAD and a remote packet-mode DTE using X.25.
  • X.75 --- Defines the protocols for communication between two PSDNs.
  • X.121 --- Defines the address encoding used in PSDNs.

Figure 4-7 illustrates the main packet switching recommendations.

Figure 4-7 CCITT Packet-Switching Recommendations

4.3.2 Related OSI Standards

DECnet-Plus for OpenVMS also implements the following PSDN-related standards from OSI:

  • Connection-Oriented Network Service (CONS) --- OSI Transport Classes 0, 2, and 4 over X.25 subnetworks
  • Connectionless-mode Network Service (CLNS) --- OSI Transport Class 4 over X.25 subnetworks
  • Link Access Protocol Balanced (LAPB) to exchange frames between a DTE and a DCE
  • LLC Type 2 (LLC2) for communications over a LAN

4.4 How Connections Are Made and Data Is Transferred

To establish a call and transfer data between DTEs via a PSDN, physical and logical connections must be made between the calling and called DTE.

4.4.1 Physical Connections

To transfer data, the DTE and DCE must be connected. This connection can take many forms but, in general, the connection is made using a physical line. Two types of line can be used to connect a DTE and a DCE:

  • Leased lines
    These are for the exclusive use of one DTE and are available only for communication between that DTE and the PSDN.
    Leased lines are also known as dedicated or private lines.
    Data transmission over leased lines is always synchronous and is usually full-duplex. Typical speeds of data transmission are in the range of 2400 to 64 000 bits/s. Packet-mode DTEs are usually connected to DCEs by leased lines.
  • Dial-up lines
    These are similar to public telephone lines and are available to more than one DTE.
    Dial-up lines are also known as switched lines or telephone lines.
    Data transmission over dial-up lines is usually asynchronous. Typical speeds of data transmission are in the range of 100 to 2400 bits/s. Character-mode DTEs are usually connected to DCEs by dial-up lines via a PAD.

4.4.2 Logical Channels

The physical line between a DTE and a DCE is divided into a number of logical channels. Logical channels allow many virtual circuits to exist on the physical line. Each logical channel is identified by a logical channel number (LCN), contained in the packet header of every packet sent across a PSDN.

Before data can be sent across a PSDN, a virtual circuit must be established between a logical channel at the calling DTE and a logical channel at the called DTE. The circuits are referred to as "virtual" because a number of virtual circuits may use the same physical circuit to transmit packets from the calling DTE to the called DTE.

It is important to realize that the logical channel used between a DTE and DCE only has local significance. It is the responsibility of the PSDN to map the logical channels used by the calling and called DTEs into an end-to-end virtual circuit. This means that although a virtual circuit has end-to-end significance between the DTEs, different logical channels can be used by the virtual circuit on each side of the PSDN.

This concept is illustrated in Figure 4-8 in which two virtual circuits are depicted. Virtual Circuit A establishes an end-to-end connection using LCN 2 between the calling DTE and its associated DCE, and LCN 1 between the called DTE and its associated DCE. Similarly, Virtual Circuit B establishes an end-to-end connection using LCN 4 on both sides of the PSDN.

Figure 4-8 Virtual Circuits Versus Logical Channels

Previous Next Contents Index