The resurrection of APPN

The days when Advanced Peer-to-Peer Networking evoked abject apathy from the Systems Network Architecture mainframe user community may soon be coming to an end.

Thanks to Cisco Systems, Inc. and Bay Networks, Inc., which recently added APPN support to their respective router lines, APPN now joins Data Link Switching (DLSw) and RFC 1490-based frame relay encapsulation as yet another strategic means for realizing SNA-capable, multiprotocol local-area and wide-area networks.

IBM introduced APPN nine years ago as the successor to SNA. However, APPN's use has been restricted largely to AS/400 networks, although APPN has been able to support mainframe-based networks since 1992. A major impediment to APPN's success within mainframe-centric networks has been its inability to offer unrestricted native support for traditional SNA 3270 datastreams, which make up nearly 90% of the traffic associated with mission-critical applications.

Cisco and Bay Networks intend to fix this problem by providing what I call a surrogate dependent logical unit support feature as part of their respective APPN Network Node (NN) routing support strategies. This feature will enable bridge/router-based APPN networks to support traditional SNA traffic from any SNA device, even if the device does not contain its own dependent LU Requestor (dLUR) software. This capability is what makes the Cisco and Bay Networks initiatives noteworthy; IBM 6611 and 3Com Corp. NetBuilder II routers have supported APPN NN routing for a while now.

IBM's current dLUR solution is contingent on the presence of dLUR software in every SNA device - and, unfortunately, dLUR software currently is available only for 3174 controllers and personal computers running OS/2. With the surrogate dependent logical unit function, a customer can theoretically support any and every SNA device. As a result, mainframe network managers at last will be able to contemplate an APPN-based multiprotocol solution, albeit based on Cisco or Bay Networks bridge/routers, without having to worry about how they are going to support their bread-and-butter SNA traffic with APPN.

The pros and cons of implementing multiprotocol networks that use DLSw vs. RFC 1490 already have been discussed in detail (NW, May 1, page 34). We now have to see how APPN stacks up against these two techniques.

APPN's quintessential strengths, in addition to its peer-to-peer networking capability, include its ability to dynamically discover remote destinations and register endstation resources. APPN also has a sophisticated class-of-service-based path selection and traffic prioritization mechanism.

Offsetting these strengths are APPN's inexcusable inability to support dynamic alternate routing, as well as the absence of SNA-like transmission groups, which would allow network managers to configure multiple parallel links to guard against the failure of any single link and ensure load balancing across all the links. Despite these weaknesses, APPN's dynamic destination discovery and class-of-service capabilities alone make it a compelling networking scheme for complex, far-flung networks.

However, APPN tends to excel only in peer-to-peer networks consisting of APPN End Nodes with many potential destinations - ideally, a relatively meshed network with many alternate paths to various destinations via intermediary APPN NNs.

In networks that do not meet most of these conditions, APPN's luster tends to pale. SNA users with mainframe-centric networks need to be particularly cognizant of this fact when considering bridge/router-based APPN. If SNA 3270 datastreams destined for one or more mainframes make up the bulk of a user's traffic, DLSw or RFC 1490 may prove to be equally, if not more, effective choices than APPN.

Users with multiple mainframes should also note that APPN NN routing does not exactly replicate the traditional SNA subarea-to-subarea routing routinely used in multimainframe networks. APPN NN routing can be made to emulate SNA routing that is, use the same paths that would have been utilized by SNA.

However, doing this requires manually customizing class-of-service tables to favor the SNA-compatible paths. APPN does not have a built-in option that can be activated to ensure backward compatibility with SNA subarea routing.

For current APPN users or SNA users migrating to LU 6.2-based peer-to-peer client/server applications, APPN NN routing that is enhanced with the surrogate dependent logical unit feature is an attractive option. IBM's formal unveiling of High Performance Routing (HPR) last month (NW, May 29, page 1), as well as Cisco's announcement of products supporting HPR (NW, May 22, page 6), make this option even more appealing. HPR, which is being positioned as the eventual successor to both SNA and APPN, will enhance APPN by providing dynamic alternate routing, very fast intermediate node routing, true multilink transmission groups and a very powerful, anticipatory congestion control mechanism.

Nonetheless, as with APPN, HPR's true power can only be realized in a distributed, peer-to-peer net with many alternate routes and HPR-based intermediate nodes. If APPN or HPR nodes were deployed in, say, a frame relay network, many of the value-added functions of APPN or HPR would likely be nullified. For example, frame relay, not HPR, would handle any necessary dynamic alternate routing within the net. Thus, it is always important to remember that the advantages that can be derived with APPN or HPR are not automatic, but dependent on the exact configuration of the net.

Bearing that in mind, APPN - and in future, HPR - gives users yet another valuable option for migrating from today's SNA networks to next-generation multiprotocol networks.

Guruge is an independent consultant specializing in internetworking and IBM network architectures. He can be reached at (603) 878-1303 or via the Internet at aguruge@mcimail.com.