Guest

IBM Networking

APPN Components and Features

Table Of Contents

APPN Components and Features

APPN Technology Overview

APPN Components and Node Types

NN

NN Server

EN

LEN Node

CNN

CP

BrNN

HPR Node

ICN

DLUR/ DLUS

Dependent and Independent LUs

Border Node

Migration Data Host

Transmission Group

VRN

CDS


APPN Components and Features


APPN Technology Overview

An SNA node is a set of hardware and associated software components that implement the functions of the seven SNA architectural layers. Although all seven layers are implemented within a given node, nodes can differ based on their architectural components and the sets of functional capabilities they implement.

Every node defined by SNA contains a CP. A PU 5 subarea node contains SSCP. An SSCP activates, controls, and deactivates SNA resources in the network. The CP in a PU 2.1 node is called simply a CP. In general, a CP manages the network resources such as PUs, LUs, and sessions.

Advanced Communications Function (ACF)/VTAM in CS/390 contains a CP that manages SNA devices in its span of control (that is, within its domain). In general, all devices within the VTAM domain must be configured to that VTAM, but VTAM can dynamically find resources "owned" by another VTAM. VTAM is responsible for establishing all sessions and for activating and deactivating resources in its domain. In this environment, resources are explicitly predefined, thereby eliminating the requirement for broadcast traffic and minimizing header overhead.

A PU provides services needed to manage a specific type of device and any resources associated with the device. A PU is composed of software, hardware, and microcode. It represents a set of functions. If software such as IBM's VTAM performs these functions, then the software represents the PU. A PU can also be a piece of hardware, such as a FEP. For some devices (for example, an IBM 3174 controller), the PU function is included within the terminal's microcode.

The following list includes the PU types within the SNA architecture:

PU 5 (mainframe)

PU 4 (FEP)

PU 2.0

PU 2.1 (LEN)

PU 1

APPN Components and Node Types

The components and node types that make up the APPN architecture are as follows:

NN

NN server

EN

LEN node

Composite network node (CNN)

CP

BrNN

HPR node

ICN

DLUR/DLUS

Dependent and independent LUs

Border node

Migration data host

Transmission group

VRN

Central directory server (CDS)

NN

NNs make up the backbone routers in an APPN network. Together with the links that interconnect them, the NNs form the intermediate routing network of an APPN network. The NNs connect the ENs to the network and provide resource location and route selection services for them.

A NN provides the following functions for ENs and LEN nodes:

Distributed directory services

Topology database exchanges with other APPN NNs

Session services for local LUs and client ENs

Intermediate routing services

The original APPN architecture was defined so that NNs maintain both local and network topology databases. When an EN requests a session setup for a pair of resources, the NN will first look in its directory to see if it knows the location of the destination. If it does, session setup can proceed. If it does not know the location of the destination, the NN will send a broadcast throughout the network to locate the destination. When the destination is found, the NN adds information about the destination to its directory, selects a session path to meet the COS defined in the session setup request, and then tells the EN to complete session setup.

NN Server

A NN server is a NN that provides resource location and route selection services to the LUs that it serves. These LUs can be in the NN itself or in the client ENs. A NN server uses CP-to-CP sessions to provide network information for session setup in order to support the LUs on served APPN ENs. In addition, LEN ENs can take advantage of the services of the NN server.

EN

An EN is located on the periphery of an APPN network. An EN obtains full access to the APPN network through one of the NNs to which it is directly attached and serves as its NN server. There are two types of ENs: APPN ENs and LEN ENs. The APPN ENs provide limited directory and routing services only for local resources and support APPN protocols through a NN server. A LEN EN is a LEN that is connected to an APPN NN. Although the LEN EN lacks the APPN extensions, it is provided services through its NN.

LEN Node

A LEN node provides peer-to-peer connectivity to other LEN nodes, APPN ENs, or APPN NNs. A LEN node requires that all network accessible resources, either controlled by the LEN node itself or on other nodes, be defined at the LEN node.

Unlike APPN ENs, the LEN node cannot establish CP-to-CP sessions with an APPN NN. A LEN node therefore cannot register resources at a NN server. Nor can it request a NN server to search for a resource or to calculate the route between itself and the node containing a destination resource. It does, however, use the distributed directory and routing services of an adjacent NN indirectly. It does this by predefining remote LUs, owned by nonadjacent nodes, with the CP name of an adjacent APPN NN.

CNN

A CNN is a PU 5 node (VTAM) along with its subordinate PU 4 nodes (NCP, which runs in the FEP). Unlike VTAM, which can be a standalone NN or EN, NCP cannot provide this capability. Therefore, working together, they can represent a single NN.

CP

The CP in a PU 2.1 or PU 5 node is simply called a CP. Like other CPs, it has a number of functions: it can activate locally attached links, interact with a local operator, and manage local resources. It can also provide network services, such as partner location and route selection, for local LUs in a subarea network.

A CP for a LEN node does not communicate with a CP in another node. It communicates only with other components in its own node for controlling local resources and for aiding local LUs in establishing LU-to-LU sessions.

An APPN EN CP participates in CP-to-CP sessions with the CP in an adjacent NN server. Two parallel sessions using LU 6.2 protocols are established between the partner CPs. The APPN EN does not establish CP-to-CP sessions, however, with any adjacent LEN node or APPN ENs. If it is attached to multiple APPN NNs, the APPN EN chooses only one of them to be its active server; it does not establish CP-to-CP sessions with more than one NN at a time. (It can, however, route LU-to-LU sessions through any adjacent NN as determined by route selection criteria.)

BrNN

The SNASw BrNN feature eliminates the need for the full NN functionality in the network and provides a more scalable solution by effectively eliminating SNA topology and broadcast search traffic from the network.

HPR Node

An HPR node is an APPN node that has implemented the optional HPR functions. An HPR node can be an APPN EN or an APPN NN. HPR is an enhancement to APPN that provides improved network performance and reliability. HPR replaces ISR with two elements: ANR and RTP.

APPN HPR is capable of SNA session recovery. In case of a route failure, the RTP layer selects an alternate path and reroutes SNA packets. Before HPR, neither SNA nor APPN was capable of LU-to-LU session recovery. Within HPR, RTP provides end-to-end processing, reordering, and delivery of frames, which produces nondisruptive route switching and flow control. On the other hand, ANR provides node-to-node connectionless source routing. These features of HPR create a protocol that is similar in functionality to TCP/IP.

ICN

The most common migration step for a multidomain network is to move the CMC VTAM subarea host to an ICN. An ICN combines the function of a subarea node and a NN. It implements APPN NN, SSCP, and cross-domain resource manager (CDRM) functionality. An ICN is located on the border of an APPN network and a SNA subarea network. The node converts session requests between subarea SNA and APPN protocols, thus enabling sessions to be established between applications residing on an APPN VTAM host to LUs residing in the subarea network.

An ICN can own and activate NCPs. It communicates network control data by using SSCP-to-SSCP sessions with other subarea nodes and CP-to-CP sessions with other APPN nodes. To enable it to participate in the subarea network, it is defined with a unique subarea number and requires subarea path definition statements. An ICN can be connected to other APPN nodes, LEN nodes, and subarea nodes.

DLUR/ DLUS

The functionality of the DLUR/DLUS was a direct result of the thousands of SNA devices that still require the master/slave relationship for network connectivity and data delivery over APPN. The DLUR functionality is implemented in an APPN EN or NN (remote to VTAM), whereas DLUS is implemented in a VTAM APPN NN (version 4.2 or higher).

Dependent and Independent LUs

In SNA subarea networks, LUs that reside in peripheral nodes can be dependent (SSCP-dependent) or independent (SSCP-independent). An independent LU is dependent or independent based on the protocols it uses to initiate LU-to-LU sessions.

An independent LU sends a session-activation request to another LU. No SSCP intervention is required. LUs reside in PU 2.1 nodes.

In APPN networks, independent LUs establish sessions directly with partners by sending session-activation requests directly to the partner. Allowing independent LUs to establish direct sessions with other independent LUs (without the intervention of VTAM) is referred to as peer-to-peer communication.

APPN independent LUs can dynamically register themselves to their NN server. ENs issue a Locate request to their NNs to dynamically locate APPN resources. When an EN sends a directory search to a NN, the NN forwards a Locate to all of its NN neighbors, and the neighbors propagate the Locate throughout the network. When the resource is found, the directory is updated, and the EN is informed of the resource location.

When a NN initializes, it exchanges its topology with its directly attached neighbors. Every time a change occurs in the topology database of a NN, the NN propagates the change to all directly attached NNs. In this manner, all NNs have an exact copy of the topology database. From this topology database, each NN builds one or more trees, with itself as the root (there is one tree per COS).

When a session is established, the best path from source to destination is determined. The same path is used for the duration of the session.

A dependent LU uses SSCP-to-LU sessions to send session-initiation requests to the controlling SSCP. The dependent LU depends on the SSCP to conduct the session initiation with the target LU and requires an SSCP-to-LU session. APPN provides support for SSCP-dependent LUs using DLUR/DLUS.

The DLUS is a product feature of a PU 5 (VTAM) NN. The DLUS function enables VTAM to have SSCP services for dependent LUs in remote APPN ENs or NNs; the ENs and NNs act as the DLUR.

Border Node

Base APPN architecture does not allow two adjacent APPN NNs to connect and establish CP-to-CP sessions when they do not have the same network identifier (NETID). The border node is an optional feature of an APPN NN that overcomes this restriction. A border node can connect to an APPN NN with a different NETID, establish CP-to-CP sessions with it, and then allow session establishment between LUs in different subnetworks. Topology information is not passed between the subnetworks. In addition, a border node can also connect to another border node.

Migration Data Host

A migration data host is a VTAM data host that communicates to APPN resources as an APPN EN and communicates to directly attached VTAMs and NCPs using subarea flows. Unlike an ICN, a migration data host does not translate between APPN and subarea protocols, and it cannot own NCPs or provide ISR. A migration data host is often implemented during migration from subarea SNA to APPN because the migration allows data hosts to be accessed from an APPN node or subarea node concurrently.

Transmission Group

A transmission group is the same in APPN terminology as it is in legacy SNA. A transmission group is the set of lines connecting two nodes. The difference between a transmission group in SNA and in APPN is that the current APPN architecture limits a transmission group to a single link, although multilink transmission groups are expected to be implemented in the future. The topology database contains NNs and transmission groups that connect NNs.

VRN

A VRN represents a connection to the SATF, such as Token Ring and FDDI. The SATF and the set of nodes having defined connections to a common VRN are said to comprise a connection network.

CDS

A central directory server is a NN that builds and maintains a directory of resources within the network. The purpose of a CDS is to reduce the number of network broadcast searches to a maximum of one per resource. NNs and ENs can register their resources with a CDS, which acts as a focal point for resource location information.

A CDS can be involved in APPN EN resource registration. An APPN EN registers its resources to improve network search performance. When an APPN EN registers its resources with its NN server, it can request that its NN server also register them with a CDS. Entries in a directory database can be registered, defined, or dynamic.

When a NN receives a search request for a resource that has no location information, the NN first sends a directed search request to a CDS, if there is one. The CDS searches in its directory for information about the location of the resource. If it does not find the location of the resource, the CDS searches ENs in its domain, other NNs and ENs, and, if necessary, the entire network (via a broadcast search). If the resource is still not found, the CDS notifies the NN that originally requested the search that the search is unsuccessful. A central directory client is a NN that forwards directory searches to a CDS.