HP OpenVMS Systems Documentation

Content starts here

DECnet-Plus for OpenVMS
Introduction and User's Guide

Previous Contents Index

2.8.6 DECnet-Plus Event Dispatcher (EVD)

The DECnet-Plus for OpenVMS Event Dispatcher (EVD) software reports significant events that occur during network operation. An event is an occurrence of a normal or abnormal condition that an entity detects. As directed by you, DECnet-Plus for OpenVMS maintains records of specific or general categories of events. These records can help you track the status of network components.

Many events are informational. They record changes that you or the DECnet-Plus for OpenVMS software makes to components of the local system, or to those remote system entities that the local system's Event Dispatcher is tracking. Other events report potential or current problems in the physical parameters of the network.

You can set up event dispatching on a particular system, between two systems, or across multiple, distributed systems. The event-dispatching component can report events that occur on any system that runs DECnet-Plus software, and it is also capable of logging the events of remote Phase IV nodes via the DECnet-Plus Event Dispatcher relay.

2.8.7 CMIP Management Listener (CML)

The CMIP Management Listener (CML) is the DECnet-Plus management module that implements DNA Common Management Information Protocol (DNA CMIP). CMIP defines the exchange of network management information.

CML provides access to CMIP. NCL accesses management directives defined for DECnet-Plus entities using CMIP.

Part II
Conceptual Information

Part II consists of two conceptual chapters that describe fundamental DECnet-Plus networking and X.25 networking concepts. This section includes the following chapters:

  • Chapter 3 --- DECnet-Plus for OpenVMS Concepts
  • Chapter 4 --- X.25 Networking Concepts

Chapter 3
DECnet-Plus for OpenVMS Concepts

All Open Systems Interconnection (OSI) communications software implements global standards that are developed by the International Organization for Standardization (ISO). An OSI standard specifies a protocol or defines a service for one functional layer of the OSI Reference Model.

This chapter introduces OSI architecture, protocols, and standards, and how they apply to DECnet-Plus for OpenVMS.

3.1 Communications Architecture: The OSI Reference Model

The OSI Reference Model is a hierarchical architecture of seven layers for data exchange between systems with incompatible operating systems. The architecture provides standard protocols, services, and interfaces so systems that implement these standards can communicate. Figure 3-1 shows the OSI layers.

Figure 3-1 OSI Reference Model

Table 3-1 lists the functions of the OSI layers.

Table 3-1 Layers of the OSI Reference Model and Their Functions
Layer Name Responsibilities
Upper Layers
7 Application Provides for distributed processing and access; contains the application programs and supporting protocols (including File Transfer, Access, and Management (FTAM) and the Association Control Service Element (ACSE)) that use the lower layers; has no formal upper boundary, since it includes application programs and their individual user interfaces.
6 Presentation Coordinates the conversion of data and data formats to meet the needs of the individual application processes.
5 Session Organizes and structures the interactions between pairs of communicating application processes.
Lower Layers
4 Transport Provides reliable, transparent transfer of data between end systems, with error recovery and flow control.
3 Network Permits communications between network entities in open systems on a subnetwork, intermediate systems, or both.
2 Data Link Specifies the technique for moving data along network links between defined points on the network, and how to detect and correct errors in the Physical layer.
1 Physical Connects systems to the physical communications media.

3.1.1 Comparison of DNA Phases

DNA Phase V integrates the lowest four architectural layers of OSI and DNA, while also offering the upper three layers of both DNA and OSI. Table 3-2 shows the names of the DECnet-Plus layers with the corresponding DNA Phase IV names.

Table 3-2 Layer Names: DNA Phase IV and DNA Phase V
DNA Phase IV DNA Phase V
DECnet and User Application layer DECnet, OSI and User Application layer
Session Control layer Presentation, Session layers
End Communications layer Transport layer
Routing layer Network layer
Data Link layer Data Link layer
Physical Link layer Physical layer

3.2 Data Flow

Except for the Application layer, each layer provides a service to the layer immediately above (its user). Every layer is supported by all the lower layers, and adds functional value to the service available from the layer immediately below. For example, the Transport layer adds in-sequence delivery of data and also retransmission of data lost by the lower layers. Figure 3-2 shows how data flows during communications.

Figure 3-2 OSI Reference Model: Data Flow

Entities within each layer on one system use the services provided by its next lower layer to communicate with other (peer) entities on a second system.

3.3 OSI Terminology

The Reference Model is a network design of layers that work together. Each layer is an independent and self-contained group of interconnected functions with its own purpose and protocols. Layers also provide services. Each layer uses the services provided by the layer beneath it.

For each layer, OSI has two types of international standard:

  • Protocol specification --- defines the protocol rules and formats.
  • Service definition --- describes the capabilities of the protocol or the service it provides.

3.3.1 Protocols

A protocol is a set of rules and procedures. Protocols govern the behavior of open systems at each layer. Some layers (for example, the Application layer) have several protocols.

A protocol machine is software that implements a particular protocol.

A protocol data unit (PDU) is information made up of protocol control information (PCI) from the current layer and, possibly, user data from the layer above. PDUs are exchanged between peer protocol machines using service primitives. A given service primitive can correspond to zero, one, or more PDUs. The integrity and identity of a PDU remains intact while it is being exchanged.

The underlying layer places each PDU received from the above layer into a service data unit (SDU). The SDU becomes user data in the PDU of its underlying layer. PDUs remain intact until they arrive at the protocol machine of the peer entity. The peer's protocol machine separates the PCI from user data and processes the PCI. Figure 3-3 shows the relationships among the PCI, user data, SDUs, and PDUs.

Figure 3-3 The Relationship of PDUs, User Data, and SDUs

3.3.2 Protocol Stacks (Towers)

Applications can communicate with each other only if they agree on the protocols they both will use and the operational parameters of these protocols. Also, exact address information is needed to indicate to each layer of protocol where to deliver data. This required information is encoded in a protocol stack or protocol tower, which is a data structure for encoding address and protocol information about a service user (application). The tower is a protocol sequence (an ordered list of protocol identifiers for each layer from the Network layer upward) with associated address and protocol-specific information.

3.3.3 Dialogues

OSI protocol machines ensure that open systems can establish message exchanges, called dialogues. Though many dialogues can occur simultaneously, each dialogue is independent of other dialogues. Protocol machines cooperate to conduct a dialogue through a predictable sequence of states. The portion of a dialogue conducted at the Application layer is called an association; the portions of dialogues conducted at other layers are called connections.

Associations or connections are established between service users by their peer service providers; for example, the Association Control Service Element (ACSE) establishes FTAM associations. Connections use the name of the service provider that establishes them; for example, a connection established by Presentation for ACSE is called a presentation connection.

3.3.4 Entities

Protocol machines operate within system-specific implementations, or processes. For every dialogue, one or more processes activate the protocol machines of each layer independently. An instance of such protocol-machine activity is called an entity. OSI entities, which are the manageable components that make up the network, relate to entities on other systems for example, a routing circuit. The relationship between processes and entities is implementation-specific.

Each entity communicates with equivalent entities on different systems, called peer entities.

3.3.5 Services

A service is an interface provided by a service element or a layer for accessing one or more functions. An application service element (ASE) is a component that provides an application-level function. FTAM and ACSE are examples of service elements.

The service element or layer that provides a service is called a service provider. An application program, service element, or layer that uses a service is called the service user. Service Primitives

To request or receive indications of a service, peer entities exchange messages called service primitives. A service primitive carries parameter values for a specific service. There are two pairs of service primitives:

  • Request and indication primitives --- exist for all services
  • Response and confirm primitives --- exist for confirmed services

Each pair of service primitives generates only one unit of user data, a protocol data unit (PDU).

Service users and service providers originate primitives as follows:

  • Request and response primitives begin with service users, which use those primitives to request services and negotiate parameter values.
  • Indication and confirm primitives begin with service providers, which use those primitives to pass on information that comes in for their users. Service Access Points (SAPs)

A service provider delivers services to a service user at an interface called a service access point (SAP). A SAP is the point at which an entity provides a service to a user entity in the layer above.

Figure 3-4 shows how a service user, a service provider, and a SAP interact.

Figure 3-4 Service User, Service Provider, and SAP Interaction

Except for the Application and Physical layers, SAPs exist at the boundaries of all OSI layers. SAPs are named according to the layer providing the services. For example, transport services are provided at a Transport SAP (TSAP) at the top of the Transport layer and any SAP that the Presentation layer provides is called a Presentation SAP (PSAP). Figure 3-5 illustrates SAP nomenclature.

Figure 3-5 SAPs at Different OSI Layers

SAPs are logical constructs defined by an identifier called a SAP selector. To create a SAP, a system manager or application user defines a unique SAP selector for a specific layer. SAP selectors are the building blocks of addresses.

A given address takes the name of the uppermost SAP that contributes a selector to the address. For example, a presentation address accesses the Application layer.

A presentation address (p-address) contains one or more SAP selectors at the upper layers. The composition of a given address depends on the purpose of the address. For example, an address that allows the Transport layer to access the Application layer has SAPs at three layers: Transport, Session, and Presentation. A p-address is used for upper-layer addressing and has SAPs at four layers: Network, Transport, Session, and Presentation.

In addition, on a LAN, the Data Link layer uses the source service access point (SSAP) and the destination service access point (DSAP):

  • SSAP --- 1-byte field in an LLC frame that identifies the link service access point (LSAP) of the sending client protocol. (The LSAP is the ISO 8802-2 (LLC) protocol identifier that identifies a Network layer entity.)
  • DSAP --- 1-byte field in a LLC frame that identifies the LSAP of the receiving client protocol.

3.4 The Upper Three OSI Layers

Each of the upper three layers provides services for user and application processes.

The Session layer service is used by a pair of communicating application processes to structure and control their dialogue, conducted over the transport connection.

The Presentation layer works in conjunction with the Session layer to provide a specialized data transfer service to the Application layer. It coordinates any necessary conversion of data between a pair of communicating application processes.

Because the semantics and syntax used by one application are unlikely to be the same as those used by another on a different system, the Presentation layer transfers data in a system-independent way. The data must be in a form that both applications can recognize; for example, data with floating-point numbers can pass between two systems even if each system has a different internal representation of floating-point numbers.

The Application layer contains many different entities, including the parts of an application program that interact with the communications environment on a system. The Application layer has a mixture of standard protocols. Some directly support application processes, others support those that give direct support to the application processes, and some do both, such as the ACSE protocol.

3.4.1 Presentation and Session Entities

Presentation and Session entities provide the Presentation and Session connections. To form an association, an OSI application entity requires a corresponding Presentation entity and Session entity. For the FTAM software, for example, these Presentation and Session entities occur within the same process as the FTAM entity.

The combined effect of the Presentation and Session entities is to manage data transfer for Application entities. For OSI applications:

  • Presentation handles syntax transformation and also establishes Presentation contexts and manages them, if necessary.
  • Presentation and Session both perform connection management functions for their own connections.
  • Session also transfers information and manages each dialogue between peer Application entities.
  • Presentation supports this use of Session services by providing the Application layer with a set of services that correspond to the data-transfer and dialogue-management services of the Session layer.

3.5 DNA Session Control Layer

The Session Control layer provides the DNA user and application interfaces. Session Control performs address resolution and selection, connection control, and manages transport connections on behalf of applications. It also supports the applications environment, including $IPC and $QIO programming interfaces.

3.5.1 Objects and Applications

The terms "object" and "application" are used differently in DECnet-Plus than in Phase IV:

  • A Phase IV object (also referred to as a Phase IV application) is a DIGITAL or user-written component that is identified by a number and associated name (for example, object number 27 for mail). This information is stored in an object database at each Phase IV node.
  • A DECnet-Plus application is equivalent to a Phase IV object. DECnet-Plus applications are identified by program name and can be specified in the application database at the system.
  • A DECnet-Plus object or object entry is a resource name stored in a namespace. The resource can be a system, a service made available by an application, or some other resource.

3.5.2 Protocol Towers

The sequence of protocol identifiers in a protocol tower typically extends from the Network layer up to the DNA application. Session Control builds and maintains multiple towers for the local node object: one tower for each protocol and each address through which Session Control can access the object. A protocol tower set includes all the protocol towers that the system builds for the object.

When a DNA application on one node requests a connection to another node, Session Control requests that DECdns provides DNA$Towers attribute information for the remote node. Session Control compares the tower information with the tower information it maintains for the local node and selects a protocol tower common to both nodes. The connection is then made automatically without a user or application needing to know what lower-layer protocols the nodes are using.

3.5.3 Address Resolution

The Session Control layer maps the global name of the node object with a set of protocols and addresses that can be used to communicate with that node. The Session Control layer performs the following functions for address resolution:

  • Maintains, in the namespace, the following information in the DNA$Towers attribute for local objects:
    • Protocols supported on the local system
    • DECnet-Plus network address of the local system
  • Obtains information about the remote object from the namespace to determine the sequences of protocols and address information required to communicate with the remote node or application.
  • Selects all common towers and passes this information to the address selection function.

You can autoconfigure addresses for DECnet-Plus systems, which can change over time. Session Control creates and maintains the protocol and address information in the towers in the namespace for the node object entry.

Session Control supports a RegisterObject function to maintain the address attribute of an object entry if the underlying protocol tower address element of the node changes. Applications can request that Session Control perform this function for their objects.

3.5.4 Address Selection

The Session Control layer initiates a connection based on the address of a system and the Session Control application being connected to that system. It receives a list of common protocol towers with the address-resolution function and looks for a set of mutually supported protocols. It tries to make a connection using all towers in common; the connection fails if all towers are tried and none works. The selected protocols and address information are used for communication with the remote system.

3.5.5 Connection Control

The Session Control layer performs connection services for Session Control applications. It requests, maintains, and disconnects or aborts transport connections. Session Control can request a connection using the destination address. It can receive a connect request, validate the access control information supplied with the request, and identify the remote application making the request. The Session Control layer sends and receives data over transport connections.

The Session Control layer forms the interface between all DNA applications and the Transport layer. It allows use of the NSP Transport and OSI Transport protocols.

3.5.6 DIGITAL-Supplied Session Control Layer Applications

Session Control applications in DECnet-Plus for OpenVMS provide general-purpose network services. A Session Control layer application is identified by application type, which is a discrete numeric identifier for either a user task or a DECnet-Plus program, such as file access listener (FAL). DECnet-Plus for OpenVMS uses application type numbers to enable logical link communications using the NSP Transport Service or the OSI Transport Service.

DECnet-Plus has two types of Session Control applications:

  • Applications with a 0 application type
    These applications are usually user-defined images for special-purpose applications. They are named when a user requests a connection.
  • Nonzero applications
    Nonzero applications are known applications that provide specific network services such as FAL. They can also be user-defined tasks; these applications should be for user-supplied known services. Application type numbers for all nonzero applications range from 1 to 255. The number serves as a standard addressing mechanism across a heterogeneous network.

Previous Next Contents Index