Advanced Peer-to-Peer Networking (APPN) is a network architecture that supports distributed network control. It makes networks easy to configure and use, provides centralized network management, and supports flexible connectivity.
An APPN network is composed of type 2.1 nodes. Each node in the network is connected by a link to at least one other node in the APPN network. CP-CP sessions are established over each of these links to adjacent nodes (nodes in the same network that can establish direct links without going through a third node). All of the nodes in an APPN network share a common network name.
APPN nodes can include processors of various sizes, such as the Application System/400 (AS/400), PCs running CS/NT, systems using Virtual Terminal Access Method (VTAM), and AIX servers running CS/AIX.
APPN provides the following functions:
| Note: | An APPN node can also be connected to a subarea network, serving as both an APPN node in a peer network and a peripheral node in a subarea network. |
The following types of nodes can be part of an APPN network:
In addition, low-entry networking (LEN) nodes can be connected to an APPN network, but they do not use APPN features (see LEN Nodes).
A sample APPN network is shown in Figure 4.
Figure 4. Portion of a Sample APPN Network
View figure. |
This example shows an APPN network that includes five network nodes (NNs), three end nodes (ENs), and a LEN node. The network nodes form the backbone of the APPN network; end nodes access the network through the network nodes. LU 6.2 TPs on any node can communicate with any other LU 6.2 TPs in the network.
One of the APPN network nodes (NNA) also participates in a subarea network, connecting to a host through a communication controller. This node functions as an APPN node when communicating with nodes in the APPN network, and as a peripheral node when communicating with nodes in the subarea network. Through this network node, LU type 6.2 LUs on other nodes in the APPN network can establish LU-LU sessions with LU type 6.2 LUs on the host.
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:
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 Figure 4), 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.
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.
An APPN control point is a set of functions that manages node resources and supports both physical unit and logical unit functions on a type 2.1 node. An APPN CP directs local node functions (such as activating and deactivating adapters and links), provides directory and topology information, and assists LUs in session initiation and termination.
Adjacent nodes in an APPN network use a pair of parallel CP-CP sessions to exchange network information and to provide directory and route selection services. Both sessions of a given pair must be active in order for the partner CPs to begin and sustain their interactions. Different node types use these sessions differently, as follows:
The functions provided in CP-CP sessions vary based on the types of nodes involved, as follows:
When setting up a workstation, you must define the CP name. The CP is also an LU that can support user sessions, and it can be the only LU defined in your workstation, if you so choose.
To support communication between TPs, CS/AIX first establishes a session between the logical units that control those TPs. APPN enables the CP on a node to locate LUs throughout the APPN network without requiring that the node have any configuration information for the remote LU. The APPN function that dynamically locates LUs in the network is called directory services. Once a resource has been located, a route for the session is calculated through the APPN network.
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.
| Note: | For more information about network naming conventions, refer to Communications Server for AIX Quick Beginnings. |
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:
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 can also use wildcards in a directory entry to specify multiple partner LUs that can be accessed over a specific link.
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.
Network nodes provide directory services to other nodes in two ways:
An example of a LEN node directory is shown in Figure 5. 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.
View figure. |
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. |
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 Figure 6.
View figure. |
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.
A network node provides distributed directory services to the end nodes it serves.
An example of a network node directory is shown in Figure 7.
Figure 7. Network Node Directory
View figure. |
A network node locates a remote LU as follows:
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.
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.
APPN supports the following dynamic route selection procedures:
The APPN functions that provide dynamic route selection are known as topology and routing services (TRS) .
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:
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.
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.
| Note: |
|
As shown in Figure 8, network topology information is replicated at all network nodes, and local topology information is stored at network nodes and end nodes.
Figure 8. Network Topology Database in Network Nodes
View figure. |
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.
APPN network nodes use CP-CP sessions to exchange network topology information when a resource (such as a node or a link between two network nodes) is activated or deactivated, or when the characteristics of an existing resource change. When such a change occurs, a network node generates a topology database update (TDU) that contains node identification, node and link characteristics, and update sequence numbers identifying the resource to be updated and the changes for the resource. Each TDU is sent to all active network nodes to ensure that the network topology database is kept current throughout the network.
APPN directory services locates a specific session partner; topology and routing services calculates the optimal session route after the session partner has been located in the network. Each network node provides route selection services for sessions originated by its own LUs and by LUs at the end nodes or LEN nodes that it serves. A network node uses its own local topology information, plus information from the shared network topology database, to dynamically calculate routes between nodes.
Once the session partner has been located, the network node performs the following steps to select a route:
The LU requesting the session specifies a mode name that identifies session characteristics. The associated mode identifies a class of service that specifies requirements for the links used to route session traffic.
Depending on the specified class of service, the route calculation algorithm computes a weight value for each node and logical link and then totals the weights for each route. To select the optimal path, the network node computes the current least-weight route from the node containing the originating LU to the node containing the destination LU.
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:
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 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 Figure 9--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 Figure 9.
Figure 9. APPN Network Using a Shared-Access Transport Facility
View figure. |
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 Figure 10. For a network that includes five other nodes, Node EN1 needs five link definitions:
Figure 10. Definitions Needed for Direct Links from Node EN1 to Every Node in an APPN Network
View figure. |
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.
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:
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 Figure 11. 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.
Figure 11. Definitions Needed for Direct Links Using a Virtual Node
View figure. |
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 Figure 10), 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:
As described in the previous sections, network nodes in an APPN network need to maintain topology information (about the location of other nodes in the network and the communications links between them), and to forward this information around the network when the topology changes. As the network grows in size, the amount of stored information and topology-related network traffic can become large and difficult to manage.
It is possible to avoid these problems by separating the network into subnetworks, so that each node only needs to maintain topology information about the nodes in its own subnetwork. However, this results in increased network traffic when trying to locate resources in other subnetworks.
The Branch Extender feature of APPN, illustrated in Figure 12, provides a solution to these problems.
View figure. |
As the name implies, Branch Extender is designed for networks that can be divided into distinct areas such as separate branches of a large organization. It works by separating out branches from the main backbone APPN network (for example, the network in the organization's headquarters).
Each branch contains a node of a new type called Branch Network Node (BrNN), which is connected to a Network Node in the main APPN backbone network. The BrNN combines the functions of an APPN network node and an APPN end node.