APPN Network Nodes

An APPN network node is a type 2.1 node that provides distributed directory and routing services for all LUs in its domain. These LUs can be located on the network node itself, or on an APPN end node or LEN node for which the network node provides services. Because an APPN network node acts as the network entry point for end and LEN nodes in its domain, the network node is also referred to as the network node server for those nodes.

A network node provides the following services:

• LU-LU session services for its local LUs

• Directory searches and route selection for all LUs in its domain

• Intermediate session routing (see Intermediate Routing)

• Routing for management services (MS) data, such as alerts, between a served end node and an MS focal point

APPN End Nodes

An APPN end node is a type 2.1 node that serves as an end point in an APPN network. It maintains directory information only for local resources. An APPN end node can independently establish sessions between local LUs and LUs on adjacent nodes. For sessions with LUs on nodes not directly connected to the end node, an end node requests routing and directory information from its network node server using CP-CP sessions.

APPN end nodes can register their local LUs with their network node server. This capability means the network operator at the network node server does not have to predefine the names of all LUs on the attached end nodes to which the network node provides services.

An APPN end node can be attached to multiple network nodes (see EN3 in Portion of a Sample APPN Network), but it can have CP-CP sessions active with only one network node at a time-its network node server. The other network nodes can be used only to provide intermediate routing for the end node or as substitute network node servers if the main network node server becomes unavailable.

An APPN end node can also have a direct link to another APPN end node or a LEN node, but CP-CP sessions are never established between two end nodes.

LEN Nodes

A low-entry networking node (LEN node) is a type 2.1 node that uses independent LU 6.2 protocols, but does not support CP-CP sessions. It can be connected to an APPN network node or end node, but does not support APPN functions.

An APPN network node can provide routing services for an attached LEN node, enabling the LEN node to participate in an APPN network without requiring link stations to be defined between the LEN node and all of the nodes in the APPN network.

LUs in the APPN network with which the LEN node may want to establish sessions must be defined to the LEN node as if they reside on the LEN node's network node server. The LEN node establishes sessions with LUs on its network node server. The network node routes the session through the APPN network to the node in the network where the LU actually resides. LUs on the LEN node must be predefined to the network node that serves the LEN node. LU resources on LEN nodes (unlike those on end nodes) cannot be registered on the network node server.

An APPN end node cannot provide intermediate routing. When a LEN node's only link is to an APPN end node, the LEN node can communicate only with LUs on the end node through the direct link between the two nodes.

Resource Names

Each node has a unique name consisting of two parts: a network name and a control point name. Together they constitute a fully qualified CP name. This name identifies each node to all other nodes in the network. Similarly, each logical unit is identified by a fully qualified LU name, consisting of a network name and LU name.

Directory Services

Each APPN node maintains a directory of network resources. Directory services is the component of the node CP that manages the local directory database and, in a network node, searches for network resources throughout an APPN network.

When the node is initialized, it includes the following information:

• Node type (APPN network node, APPN end node, or LEN node)

• Network ID of node

• CP name of node

Each node directory maintains entries for resources (LUs and CPs), including each resource's fully qualified name, type, and registration status. The specific resources stored in each local directory depend on the node type:

• A LEN node maintains a directory that includes its own LUs. It must also be configured with directory entries for all of its possible partner LUs. LUs in the APPN network with which the LEN node may want to establish sessions must be defined to the LEN node as if they reside on the LEN node's network node server. The LEN node establishes sessions with LUs on its network node server. The network node routes the session through the APPN network to the proper node in the network.

  A LEN node can also use wildcards in a directory entry to specify multiple partner LUs that can be accessed over a specific link.

• An APPN end node maintains a directory that includes its own LUs. It can also be configured to store directory entries for partner LUs in adjacent nodes. This enables local LUs to establish peer-to-peer sessions with those LUs without using APPN functions.

  If a resource is not locally defined to an end node or currently cannot be reached by the end node, the end node sends a request to its network node server asking it to search the APPN network for the resource.

• An APPN network node maintains a directory that includes its own LUs and the end node and LEN node LUs in its domain. An end node can dynamically register its LUs with its network node server. (LEN nodes cannot register LUs with a network node server, so LEN node LUs must be configured on their network node server.) A network node directory can also contain cached entries for LUs that are not in the network node's domain, but whose location has been determined through a previous search.

  Network nodes provide directory services to other nodes in two ways:

  • Searching for remote resources in response to session requests from end nodes or LEN nodes

  • Responding positively to directory search requests from other network nodes when a named resource is found in the local directory

LEN Node Directories

An example of a LEN node directory is shown in LEN Node Directory. Since LEN nodes do not support CP-CP sessions, the directory for Node LEN1 must contain all the LUs with which it communicates. The directory for Node LEN1 identifies its network node server (NNA) as the location for any LUs that are not on an adjacent peer end node. Since Node LEN1 can access the LUs only through Node NNA, it defines the CP on the network node as the owning CP of all the LUs, including LUs located on the end nodes.

LEN Node Directory

To establish a session with an LU on a node that is not directly attached, Node LEN1 sends an LU-LU session activation (BIND) request to its network node server (Node NNA). The server automatically locates the destination LU and forwards the BIND.

Note

In this example, Node LEN1 can establish a session with LU1 on Node EN1 through its network node server, NNA. However, LU2 on Node EN1 is not defined in the directory for Node LEN1, so Node LEN1 cannot establish sessions with that LU.

End Node Directories

When an LU is not represented in an end node directory, the end node initiates a LOCATE search to find the desired LU. To activate the search for a remote LU, the end node invokes the services of its network node server. An example of an end node directory is shown in End Node Directory.

End Node Directory

Potential partner LUs in the APPN network do not need to be defined to the end node. However, in order for Node EN3 to establish a session with LUX on Node LEN1, the LU on the LEN node must be configured as a partner LU on Node EN3.

Network Node Directories

A network node provides distributed directory services to the end nodes it serves.

An example of a network node directory is shown in Network Node Directory.

Network Node Directory

A network node locates a remote LU as follows:

1. The network node receives a request to locate an LU. The request can be any of the following:

   • The name of a destination LU sent by an end node or a LEN node to its network node server

   • An LU name specified in a LOCATE search request from an end node

   • An LU name specified in a BIND request from a LEN node

   • An LU name specified by a TP on the network node

2. If the destination LU is not located in the network node-but appears in its directory-the network node sends a directed search request to the destination network node server to verify the location of the LU.

   If the LU is not in the network node directory, the node initiates a search of the network by sending a broadcast search to every adjacent network node.

3. Each node in turn propagates the broadcast and returns replies indicating success or failure.

For its future needs, a network node caches information obtained from successful broadcast searches.

An APPN end node can also receive (and respond to) LOCATE search requests from its network node server to search for, or confirm the continued presence of, specific LUs in the end node.

Each APPN end node registers its LUs with its network node server by sending the network node a registration message. In this way, the network node maintains current directory information for the end nodes in its domain. A LEN node cannot register LUs with its network node server. Therefore, all LUs on the LEN node must be predefined, through configuration, to the network node server.

Topology and Routing Services

Each APPN node includes a topology database that stores information about other APPN nodes and about transmission groups, which are sets of links between a specific pair of nodes. The contents of the database for a specific node depend on the node type:

• All network nodes share a copy of the network topology database. This shared database includes information about all other network nodes-including network IDs, CP names, and other node characteristics-and about the transmission groups between each pair of network nodes. This database provides a complete view of the network backbone topology-the nodes and transmission groups that can be used for routing sessions between any pair of nodes in the network.

  In addition, the topology database on each network node contains local information about transmission groups from that network node to adjacent end nodes or LEN nodes.

  The network node uses the topology database to calculate routes for sessions between LUs in its domain and remote LUs, or to provide information to other network nodes to enable them to calculate session routes.

• Each end node has a local topology database with information about transmission groups from that end node to adjacent nodes.

  The end node provides this information to its network node server as part of the request to locate an LU and calculate a session route to that LU. The network node server uses the end node topology information when calculating the session route for the end node. The end node uses this information when establishing sessions with predefined LUs on adjacent nodes. The end node topology database supports communication only with adjacent nodes.

As shown in Network Topology Database in Network Nodes, network topology information is replicated at all network nodes, and local topology information is stored at network nodes and end nodes.

Network Topology Database in Network Nodes

The shared network topology database is duplicated at Nodes NNA, NNB, NNC, and NND. In addition, each of those nodes includes local topology information (except Node NNC, which does not have any local topology information because it does not have any links to end nodes). For example, Node NNB includes information for Link f to Node EN2 and Link g to Node EN3, but it does not include information for Link i, which connects Nodes EN2 and EN3.

End nodes include information only for links to adjacent nodes. For example, Node EN2 includes information about Link f to Node NNB and Link i to Node EN3.

Intermediate Routing

Intermediate routing enables an APPN network node to receive and route data destined for another node. The origin and destination of the data can be an end node, another network node, or a LEN.

Intermediate routing supports sessions between LUs that are not on adjacent nodes. After a route has been selected for a session, APPN network nodes in the route use intermediate routing to forward session data to the next node in the route.

Resource characteristics maintained by the topology database can include congestion status. If a network node becomes heavily congested, the network node can relay this information to other network nodes in the network, making the congested network node less likely to be included in session routes calculated for new sessions.

APPN provides two types of intermediate routing:

• In intermediate session routing (ISR), available in all network nodes, the network node keeps track of each intermediate session. Each intermediate node adjusts the pacing of session data to control the rate at which data flows between adjacent nodes. Each intermediate node can also perform segmentation and reassembly of segmented data. In ISR, once a session route has been established, all data on that session uses the same route. If part of the route fails, the session ends.

• In automatic network routing (ANR), available in network nodes that support APPN's High-Performance Routing (HPR) function, intermediate network nodes can dynamically reroute session traffic if part of the route fails. ANR does not provide intermediate session pacing or segmentation and reassembly.

ANR enables intermediate nodes to route session traffic much faster than is possible with traditional APPN ISR. However, ANR requires additional overhead at the RTP (Rapid Transport Protocol) endpoints. In routes with few intermediate nodes, an ANR route might actually be slower than an ISR route, due to processing time at the endpoints. For routes containing a larger number of intermediate nodes (hops), ANR routes are typically faster. The exact location of the break-even point depends on the efficiency of the RTP nodes.

Direct Connectivity

Direct connectivity enables session traffic to travel directly between two nodes without the need for an APPN network node to route the session. In general, sessions between directly connected nodes can exchange data more quickly than sessions for which data is routed through a network node. For nodes on a shared-access transport facility (SATF)-for example, for nodes on a token ring as shown in APPN Network Using a Shared-Access Transport Facility-efficiency would be increased by defining links between every pair of nodes in your network. However, this can be a difficult task-the number of link stations is n × (n-1), where n is the number of nodes in the network.

An APPN network on a token ring is shown in APPN Network Using a Shared-Access Transport Facility.

APPN Network Using a Shared-Access Transport Facility

If Node EN1 has a link definition for each of the links in the network, it can establish a direct link to any node. The link definitions needed to support direct links between Node EN1 and every other node in the APPN network are shown in Definitions Needed for Direct Links from Node EN1 to Every Node in an APPN Network. For a network that includes five other nodes, Node EN1 needs five link definitions:

• EN1 to NNA

• EN1 to EN2

• EN1 to EN3

• EN1 to EN4

• EN1 to EN5

Definitions Needed for Direct Links from Node EN1 to Every Node in an APPN Network

If all of the nodes in the network are to support direct links to every other node, a total of 30 link definitions are needed on the six nodes in this example. In general, the number of link definitions can be calculated as n × (n-1), where n is the number of nodes in the network. In a larger network, the number of link definitions quickly becomes unwieldy. Increasing the number of link definitions between network nodes also increases the number of TDUs flowing through the network, which can degrade network performance.

APPN connection networks provide a solution to this problem.

APPN Connection Networks

For APPN networks attached to a shared-access transport facility (SATF), an APPN connection network greatly reduces the number of link definitions needed to support direct connectivity between nodes in the network. In a connection network, an APPN end node needs to configure only a single link to an adjacent network node server and a link to the connection network, instead of configuring every possible link to every node.

To use the connection network feature, an APPN network must meet the following conditions:

• The nodes in the APPN network must be linked using switched media such as token ring or Ethernet (see DLCs).

• All of the links in the APPN connection network must use the same media.

• The APPN network that contains the connection network must be fully connected. In a fully connected network, each node has at least one link that supports CP-CP sessions to an adjacent node.

In a connection network, the SATF serves as a virtual routing node (VRN) that attaches directly to each node in the connection network. The name of the connection network serves as the name of the control point for the VRN. The VRN supports the direct routing of session data between any two nodes in the connection network, but it does not establish CP-CP sessions with other nodes and it does not generate TDUs. Each node in the connection network requires only a link to its network node server.

The link definitions needed when using a connection network are shown in Definitions Needed for Direct Links Using a Virtual Node. By using a virtual node, the connection network supports direct links between Node EN1 and every other node in the APPN network, yet it requires only two link definitions.

Definitions Needed for Direct Links Using a Virtual Node

To support direct links between any two end nodes in the APPN network, a total of ten link definitions is required. (Each end node needs two link definitions: one to a network node server and one to the virtual node.) Compared to the direct connectivity requirements for an APPN network that does not use a connection network (see Definitions Needed for Direct Links from Node EN1 to Every Node in an APPN Network), you can have a much smaller number of link definitions (10 instead of 30 in this example). In a larger network, the difference in definition requirements becomes even more substantial.

A session between LUs on two nodes in the connection network is established as follows:

1. Each end node first establishes CP-CP sessions with its network node server. (If two end nodes have different network node servers, those network nodes must have a link that supports CP-CP sessions.)

2. End nodes also report their VRN links and local address information to the network node server. The local address information can be a service access point (SAP) address and a medium access control (MAC) address.

3. The server normally selects the direct link between two end nodes as the optimal route for the LU-LU session. It provides the node with the primary LU the information it needs to establish a dynamic link to the node with the partner LU.

4. The end nodes can then establish an LU-LU session without the need for intermediate session routing.