Guest

IBM Networking

APPN-to-SNA Switching Services Migration

Table Of Contents

Q&A

General

Migration Considerations


Q&A


APPN-to-SNA Switching Services Migration

General

Q. Why do I need to migrate from Advanced Peer-to-Peer Networking (APPN) to SNA Switching Services (SNASw)?

A. The traditional APPN feature set, Portable SNA (PSNA), will no longer be supported in Cisco IOS" Release 12.1 and later. The feature set has been replaced by a new second-generation Cisco APPN product, SNASw. The following milestones have been set for this process:

April 16, 2001æEnd of engineering (EOE) for Cisco IOS Release 11.2

August 13, 2001æEnd of sales (EOS) for Cisco IOS Release 12.0

October 15, 2001æEnd of engineering (EOE) for Cisco IOS Release 12.0

It is time for you and your customer to start considering migration steps from the traditional APPN features to SNASw.

Q. What requirements are addressed by SNASw?

A. SNASw addresses the following requirements:

To provide the needed SNA routing functionality

To reduce the complexity in traditional APPN environments by simplifying network designs and reducing configuration requirements

To address scalability issues associated with traditional APPN network node (NN) topologies

Q. What functionality is provided by SNASw?

A. SNASw supports APPN Branch Extender (BX), APPN Enterprise Extender (EE), and Dependent Logical Unit Requester (DLUR) functionality.

Q. What version and release of IBM OS/390 is needed to support SNASw BX?

A. To support the BX feature, OS/390 must be running at V2R5 or higher. In addition, the following authorized program analysis reports (APARs) must be applied: OW37548, OW37549, and OW39559. OW39559 is required for connection network support.

Q. What version and release of IBM Communications Server/390 (CS/390) is needed to support SNASw EE?

A. The minimum version and release of CS/390 for EE support is V2R6 with APAR OW36113 applied (the EE function was not present in the initial shipment of Release 6 but was enabled by this PTF). In addition to EE support, APAR OW36113 also provided support for the enhanced Responsive Mode adaptive rate-based (ARB-2) flow control algorithm for High Performance Routing (HPR) over IP. Responsive Mode ARB was released with EE to allow HPR Rapid Transport Protocol (RTP) to better compete with TCP for available bandwidth over IP backbones. SNASw supports both the enhanced Responsive Mode ARB (ARB-2) as well as the original ARB (ARB-1) flow control algorithm.

Q. What release of Cisco IOS software is needed to support SNASw?

A. Cisco IOS Release 12.1 or higher is required.

Q. What Cisco router platforms does SNASw run on?

A. SNASw is supported on the Cisco 2500, 2600, 3600, 4000, 7200, and 7500 Series routers, as well as the Catalyst" 5000 RSM with recommended DRAM (see Cisco CCO Software Center for more information on SNASw DRAM requirements).

Migration Considerations

This section highlights different technical aspects that customers need to consider before starting the migration process.

Q. How many upstream APPN links does each of your current network nodes (NNs) support?

A. SNASw supports approximately 10-12 host uplinks. If you are planning to have a higher number of links, then you should plan on using SNASw connection network support. SNASw support for connection network makes it possible to reduce the number of predefined links to EN application hosts in your network and significantly reduces configuration effort. A connection network is a single virtual routing node (VRN) that represents a shared access transport facility (SATF), which provides any-to-any connectivity for nodes that are attached to it. The VRN is not a physical node; it simply provides a means of defining EN link attachments to other ENs without having to explicitly define links to other ENs with which it communicates.

Q. Do you plan to have EE (HPR-only) connections adjacent to interchange transmission groups (TG)? Are any of your hosts connected to interchange nodes (ICNs)?

A. A common scenario for this is where an OS/CS/390 EE host is also an SNA Network Interconnect (SNI) gateway to another network (ICN). Prior to OS/CS/390 V2R10 (and releases prior to IBM APAR OW44611), this did not allow sessions to cross-domain subarea partners to exit an ICN via an HPR connection unless the connection was only one hop away from the target end node (EN).

Even with OS/CS/390 V2R10 (or higher) and the fix to IBM APAR OW44611 applied, there will still be one scenario that will not support HPR on an APPN link immediately adjacent to an ICN TG. This is when an ICN defines a connection to a connection network (VRN) and a session is attempted from the subarea network through the ICN and then into APPN over the VRN. The solution to addressing this limitation is to explicitly define the APPN link from SNASw to the ICN. Refer to IBM APAR OW44611 for more information regarding this limitation.

Q. Are you currently running APPN NN transport over Data-Link Switching Plus (DLSw+) to remote branch offices?

A. The primary goal of migrating from APPN NN to SNASw is the reduction of the total number of APPN NN routers. The two basic approaches to doing this are the following:

Replace DLSw+ in every branch with SNASw EE and HPR/IP (the preferred method)

Leave the existing DLSw+ network in place to the remote branches, deploy SNASw BX/DLUR in data center (or aggregation layer) DLSw+ peer termination routers to provide emulated NN services (BX) and DLUR support for downstream EN, low-entry networking (LEN) node, and physical unit (PU) 2.0 devices, and implement SNASw EE uplinks for IP Layer 3 connectivity to S/390 and zSeries NN server/DLUR primary and backup hosts (use SNASw connection network to support dynamic links to other application EN hosts)

Q. Do you have all recommended VTAM maintenance for HPR and EE?

A. The following information APAR list is the IBM recommended and essential maintenance:

II10953 VTAM HPR RECOMMENDED MAINTENANCE D

NET,VTAMSTOR,MODULE=ISTAUCLA should show UW66546 II12223

ENTERPRISE EXTENDER GENERAL INFORMATION

The following IBM APARs are recommended for customers planning to implement EE:

APAR OW36113 (OS/CS/390 V2R6)

APAR OW36458 (OS/CS/390 V2R7)

OS/CS/390 V2R10 (or V2R8 and higher with APAR OW43814 PQ38173) has an enhancement that enables the activation of EE major node definitions prior to TCP/IP startup.

Q. Are you currently implementing APPN RFC 1483 (with or without connection network) over Asynchronous Transfer Mode (ATM)?

A. SNASw provides data-link control (DLC) support compatible with having direct links between SNASw and upstream hosts and, therefore, does not support RFC 1483. When deploying SNASw over ATM, your connectivity choices are LAN emulation (LANE) or HPR/IP EE.

Q. Do you currently have cascaded APPN NN routers supporting DLUR functionality?

A. An APPN architectural restriction of DLUR/DLUS is that a DLUR can never be cascaded below another DLUR. The SNASw DLUR router must be directly connected to the upstream NN/DLUS server.

Q. Is your current APPN network topology composed of multiple APPN NNs cascaded below other APPN NNs?

A. Introducing SNASw BX/EX routers requires a careful insertion strategy if there are currently a number of cascaded NNs in the network path from the downstream device to upstream hosts. SNASw BX/EX must not have traditional NNs below it in the network configuration, so you should add Cisco SNASw routers at the bottom level (layer) of the APPN network topology as a starting point. Direct links or connection network preferably should be used for links between SNASw BX/EX routers and the CS/390 hosts instead of having a complex cascaded NN network in the middle.

This is accomplished using SNASw EX (HPR/IP) such that an IP network can connect the SNASw router EE RTP endpoint directly to upstream hosts. SNASw BX support eliminates the need for any intermediate APPN NN routing by providing all required emulated NN services to downstream SNA devices.

As previously mentioned, when a pre-existing DLSw+ WAN network is in place, SNASw can be deployed at the hub end (data center) or in the distribution (or aggregation) layers such that HPR/IP (EX) transport is supported between the SNASw data center router and the upstream S/390 or zSeries host. At the same time you can support the existing DLSw+ WAN transport of remote SNA traffic downstream into SNASw to use the SNA routing capabilities provided by SNASw BX and support for SNA dependent PU 2.0 devices by SNASw DLUR support.

Q. Do you have any secondary logical unit (LU)-initiated independent LU sessions?

A. Secondary LU-initiated independent LU sessions are not supported by SNASw. SNASw only supports primary LU-initiated independent LU SNA sessions and does not support the session services extensions (SSE) APPN option set.

Q. Does SNASw BX support host-to-host connection between VTAM hosts (APPN border node) or connections to downstream peripheral border nodes?

A. APPN ENs downstream from an SNASw BX router must be real ENs or other branch extenders acting as ENs, not border nodes or peripheral border nodes presenting an EN image. SNASw BX does not support being on the same path between two VTAM hosts (border node or extended border node implementations) or allow AS/400 border nodes acting as ENs to be downstream from a SNASw BX router (as mentioned previously, SNASw does not provide SSE NN server support).