|Previous||Table of Contents||Next|
Advanced Peer-to-Peer Networking (APPN) was developed to provide a mechanism for routing SNA traffic along with other protocols. It was typically implemented in order to link two end stationsthe benefit being that the mainframe was no longer required as an intermediary. IBM developed the protocol so that administrators wouldnt need to spend as much time predefining paths and systems, although some configurations could quickly lead to problems and quickly become more complex. The protocol also offered enhanced classes of service and mechanisms for clustering traffic into sub-areas.
While APPN is being presented in the past tense, designers should make no mistake in presuming that it is a dead protocol. Many large organizations with their roots in mainframe-based systems continue to use APPN today, although new applications are typically written for IP. Therefore, designers should be familiar with a few of the concepts behind APPN. Table 10.2 defines the more common components of APPN.
|TABLE 10.2 APPN Concepts|
|CP||The control point (CP) activates nodes or resources between nodes. The CP is also responsible for handling deactivations and the exchange of information between nodes, including topology information.|
|NN||The network node (NN) is an APPN router. It is responsible for locating and connecting sessions and resources. The NN is a PU 2.1 control point.|
|EN||The end node (EN) is effectively the application host, and it accesses the network via the NN. The EN does not participate in topology maintenance functions, including rerouting; however, it contains other APPN functionality. The EN is also a PU 2.1 control point.|
|LEN||The low-entry networking (LEN) node allows connectivity between two stations. It is a peer node that does not rely on VTAM, such as the AS/400 and the System 36. It is somewhat limited in functionalityfor example, it cannot provide routing services, nor can it use an NN server without a predefined resource.|
|CNN||The Composite Network Node (CNN) defines APPN functionality in VTAM. A combined NCP and CNN can operate as an NN.|
For years, application developers and network designers used advanced peer-to-peer networking (APPN) to link mainframe resources and other devices in the network. These solutions worked reasonably well, but they were generally difficult to configure and troubleshoot. Cisco recently announced SNASw, or Systems Network Architecture Switching Services. It transports SNA packets across IP networks and promises to simplify many of the negative aspects of APPN. Cisco also views SNASw as a possible migration path toward complete IP connectivity on the mainframe. SNASw was developed in concert with IBM.
Network Design in the Real World: SNA
While the predicted demise of the mainframe was quite premature, it is apparent that the predicted departure of SNA from the network horizon is well under way. Many shops continue to use the protocol in order to support legacy applications, but the clear majority of firms have migrated to IP.
One of the critical features in IP-based mainframe connectivity is redundancy. One option in this vein is VIPA, or virtual IP addressing. In a VIPA installation, a subnet is created within the host itself, and two distinct subnets are attached to the virtual subnettypically via the Cisco Channel Interface Processor (CIP) and ESCON connections, which greatly improve the performance of the connection between the routed network and the mainframe. However, there are other options. VIPA provides for router, CIP, ESCON interface, and ESCON connection failures, as the virtual subnet is available via the alternative path. Note that the alternative path is not used just for backupVIPA can facilitate load balancing as well.
Designers should plan for these implementations with care, noting that the mainframe IP stack typically does not support advanced or proprietary routing protocols. Therefore, it is likely that static routes or RIP redistribution will be necessary on the router.
The router may also front-end TN3270 connections to the mainframe. This removes some of the processing overhead required for terminal access.
This chapter addressed many of the issues that involve mainframe connectivity in modern network design. These issues included an overview of the encapsulation methods available for SNA traffic and the frequent need for redundancy in these installations.
This chapter also addressed the common design criteria and options associated with mainframe installations and the SNA protocol, including:
Due to both the history of RSRB and its foundation in the other protocols, designers are encouraged to make certain that they feel comfortable with RSRB from a practical perspective as well as an exam perspective. Even in organizations that have migrated to newer protocols, the concepts embedded in RSRB offer a strong foundation for the designer and administrator.
|Previous||Table of Contents||Next|