Specialized network node types

APPN was designed for implementation on a wide range of hardware platforms and operating systems, including programmable workstations, desktop computers, UNIX and Windows servers, and the IBM mainframe. The APPN function and services for the various platforms are different, depending on the APPN node role. Therefore, APPN architecture defines basic and optional sets.

All APPN nodes must adhere to the basic set of functions according to their node type (network node or end node) and they can implement one or more option sets. The requirement that an APPN node must implement the basic set defined for its role (network node or end node) assures that the node can establish APPN sessions with its peer node.

A node that implements the basic set can communicate with nodes that implement additional option sets. The two nodes learn the optional capabilities of other nodes in the network when they connect to each other and/or when they exchange network topology. (Network nodes can learn about optional capabilities of other nonadjacent network nodes through the topology database.) If an optional set is implemented in a node, the complete optional set should be implemented. There is no ability to implement subsets an optional set.

The following specialized network node types are examples of optional sets of functions.

Central directory server (CDS)

A central directory server (CDS) is implemented only in a network node. It provides more extensive functionality than the directory services in a basic network node.

When a network node receives a search request, it checks its database for the resource. If it does not find the resource in its database, it sends the request to a central directory server if one exists in the network.

When the central directory server receives a search request, it checks its database for the resource. If the central directory server that received a search request locates the resource in its own database, it verifies the information and sends a reply to the originating network node server with the location of the requested LU.

If it does not find the resource in its database and there are other central directory servers in the network, it sends the search to the other central directory servers only. If the central directory server receives a positive reply from any of the other central directory servers, it verifies the information, updates its own database with the information, and notifies the originating network node of the location of the requested LU.

If the central directory server receives negative replies from all the other central directory servers (or if there are no other central directory servers in the network), it initiates a broadcast search.

The network nodes learn about the existence and location of the central directory server through the topology database. At any given point in time, every network node knows where every reachable central directory server exists in the network.

Extended border node (EBN)

Independent SNA networks might have a requirement to be interconnected. For instance, mergers and acquisitions might require interconnecting two SNA networks or two business partners might need to exchange information.

Two subarea networks can be interconnected through SNA network interconnection (SNI). SNI is an SNA-defined architecture that enables independent subarea networks to be interconnected through a gateway.

An extended border node (EBN) is a network node capable of multiple APPN network connections, and it can maintain CP-CP connectivity with a network node that has a different NETID. Figure 1 illustrates two SNA networks connected using extended border nodes.

APPN topology information does not cross the extended border node connection or APPN subnetwork boundary, but search requests can, and an LU-LU session can be set up.An APPN subnetwork boundary is assumed when an extended border node is connected to a network node (or extended border node) with a different network identifier.

Figure 1. Two SNA networks connected using extended border nodes

Branch extender (BEX or BrEx or BrNN)

Branch extender is an extension to the APPN architecture that allows an APPN node to appear as a network node to the downstream end nodes and low-entry networking nodes and as an end node to the wide area network (WAN); see Figure 2. Implementing branch extender eliminates topology and APPN broadcast search flows between the WAN (mainframes) and the branch office.

The operations staff of the mainframe is not interested in whether a workstation in the branch is booted or powered off. The branch extender isolates the mainframe from the networking equipment in the branch. The topology and directory server of the network node part of the branch extender store the information about the branch networking equipment. The information is not propagated to the mainframe APPN databases.

Figure 2. Example of a branch extender