[an error occurred while processing this directive]

IBM Networking

SNASw Design Guide Introduction

Table Of Contents


What Is SNA Switching Services?

SNASw Technology

Branch Extender

Enterprise Extender (HPR/IP)

Dependent Logical Unit Requester/Dependent Logical Unit Server

SNASw Benefits



Usability, Serviceability, and Management

Chapter 1


What Is SNA Switching Services?

The corporate intranet is replacing the Systems Network Architecture (SNA) WAN and the IP-based enterprise network is evolving to a converged network carrying voice, video, and integrated data. SNA Switching Services (SNASw) is a new release of the Advanced Peer-to-Peer Networking (APPN) feature of Cisco IOS® Software that enables operators of enterprise networks to develop their IP infrastructures while meeting SNA routing requirements. Companies can continue to enhance and deploy a converged network based on IP while handling traffic destined for SNA-based applications without change to the application itself. SNASw provides SNA routing and, optionally, SNA transport over IP. Further, SNASw was designed to be easy to use and configure, and it includes several innovative diagnostic features.

SNASw, available in Cisco IOS Release 12.1 and later, replaces the function provided by the APPN network node (NN) feature of Cisco IOS Software. Cisco is discontinuing the APPN NN feature in Cisco IOS Software beginning with Release 12.1 because of its architectural complexity, scaling limitations, and manageability issues. Older versions of Cisco IOS Software prior to Release 12.1 are reaching their end of engineering (EOE) support as follows:

Release 11.2-April 16, 2001

Release 12.0-After March 2002

SNASw Technology

SNASw adheres to APPN architecture while offering integration with other Cisco IOS features. Networks may be designed with SNASw at the remote branch, data center, or distribution layers in conjunction with Data-Link Switching Plus (DLSw+). Traffic flowing upstream from SNASw to the data center can utilize any SNA transport facility such as Cisco Channel Interface Processors (CIPs), Channel Port Adapters (CPAs), or the IBM Open Systems Adapter-Express (OSA-Express). SNASw can help to eliminate the need for SNA routing by front-end processors (FEPs) in the network.

Branch Extender

SNASw implements the SNA node type Branch Network Node (BrNN).1 A BrNN appears as an end node (EN) to an upstream NN—usually IBM Communications Server for S/390 (CS/390)—while providing NN services for downstream ENs and low-entry networking (LEN) nodes (see Figure 1-1). This support for BrNN is also commonly referred to as Branch Extender (BX).

Figure 1-1 Branch Extender Solution

BX enhances scalability and reliability of SNA routing nodes by greatly reducing topology updates and eliminating broadcast directory storms that can cause network instability. Customers that attempted to build large SNA routed networks found that when the number of NNs exceeded about 75, scalability problems became apparent, especially as the number of APPN transmission groups between NNs increased (NN CPU utilization, memory requirements, and control flow bandwidth requirements are all a function of the number of NNs and transmission groups in the network).

The BX function eliminates APPN topology and APPN broadcast search flows between SNASw nodes and the SNA application hosts in the network. This feature is key to providing a reliable turnkey installation, because the network administrator no longer needs to develop in-depth knowledge of the level and characteristics of the broadcast directory search and topology update traffic in the network.

SNASw was also designed to be easy to configure. The number of configuration statements and parameters are fewer than those necessary for a full-scale APPN NN deployment. Various features were added so that more often than not, many remote SNASw routers could share almost identical SNASw configuration statements.

Enterprise Extender (HPR/IP)

SNASw also supports the Enterprise Extender (EE) function. This is an optional transport facility in addition to BX support. EE offers SNA support directly over IP networks by transporting SNA traffic as connectionless User Datagram Protocol (UDP) packets (see Figure 1-2). EE support on the CS/390 host allows users to build highly reliable SNA routed networks that run natively over an IP infrastructure directly to the S/390 Enterprise Servers. EE routing at Layer 3 is performed by the IP routing infrastructure. End-to-end reliability, error recovery, flow-control, and segmentation are supported using APPN High Performance Routing (HPR) and HPR's Rapid Transport Protocol (RTP).

Figure 1-2 End-to-End EE Solution

Dependent Logical Unit Requester/Dependent Logical Unit Server

Cisco supports dependent logical unit (LU) and physical unit (PU) traffic across APPN or HPR networks through the Dependent LU Requester (DLUR) feature of SNASw (see Figure 1-3). DLUR, in conjunction with the Dependent LU Server (DLUS) function of CS/390, provides the benefits of System Services Control Point (SSCP) services and allows the session data path to be different than the one being used for the SSCP-to-PU and SSCP-to-LU control session paths. This difference allows the session to take full advantage of APPN route selection dynamics.

Figure 1-3 DLUR/DLUS Support

By putting the DLUR function in the Cisco router, remote controllers need not be upgraded to support
APPN/DLUR. The dependent LUs remain visible to NetView because (CS/390) maintains awareness through DLUS-to-DLUR flows.

SNASw Benefits

Cisco SNASw contains many features and functions that allow corporations to continue their migration to an IP-based converged network that supports voice, video, and integrated data while still handling data destined for SNA applications.


SNASw was designed specifically to support the design of highly scalable, IP-based networks that also transport SNA data traffic.

Reduced Broadcasts

SNASw, because of its inherent architecture and implementation as a BrNN node type, allows the network to scale to thousands of nodes supporting tens of thousands of RTP connections with multiple SNA sessions per RTP pipe. SNASw networks will likely contain a minimum number of NNs, and they will be located at the data center. This design eliminates significant broadcast and topology update traffic from the network.

Supports High Transaction Rates

Each SNASw router can be sized according to the transaction rate it needs to support. SNASw networks can be designed with SNASw at the remote branch, at the distribution layer, or at the data center depending on the expected transaction rates, application endpoints, and IP network design.


SNASw incorporates a number of advanced routing services and transport connectivity options.

SNASw SNA Routing Services

SNASw provides the following SNA routing functions:

Routes SNA sessions between clients and target SNA application hosts using either APPN Intermediate Session Routing (ISR) or HPR Automatic Network Routing (ANR)

Supports IBM standard APPN Class of Service (COS) entries and mapping of COS to IP type of service (ToS)

Supports all types of SNA application traffic including traditional 3270 and peer LU 6.2 applications

Supports an OS/390 Parallel Sysplex configuration, working in conjunction with the CS/390 and the IBM Workload Manager, to provide higher availability in the data center using the HPR feature

Supports SSCP services to downstream dependent SNA devices using the DLUR feature

Provides dynamic link connectivity using APPN connection network (CN), which eliminates much of the configuration required in networks with numerous data hosts

Responsive Mode Adaptive Rate-Based Flow Control

Early HPR implementations failed to perform well in environments subject to packet loss (for example, Frame Relay and IP transport) and performed poorly when combined with other protocols in multiprotocol networks. SNASw supports both adaptive rate-based flow control (ARB-1) and the second-generation HPR flow control architecture, called Responsive Mode ARB (ARB-2). Responsive Mode ARB addresses all the drawbacks of the earlier ARB implementation, providing faster rampup, better tolerance of lost frames, and better tolerance of multiprotocol traffic.

Native IP Data-Link Control (HPR/IP)

SNASw support for the EE function provides direct HPR over UDP connectivity. This support is used for any interface that has a configured IP address. HPR/IP can use either the real interface IP address or a loopback interface IP address as the source address for IP traffic originating from this node.

Token Ring, Ethernet, and Fiber Distributed Data Interface

SNASw natively supports connectivity to Token Ring, Ethernet, and Fiber Distributed Data Interface (FDDI) networks. In this configuration mode, the Media Access Control (MAC) address used by SNASw is the local configured or default MAC address of the interface.

Virtual Token Ring

SNASw can connect to source-route bridging (SRB) through the use of a virtual Token Ring interface. This allows the following configuration:

Attachment to local LANs

Connection to Frame Relay transport technologies

Connection to CIPs and CPAs

Virtual Data Link Control

SNASw uses Virtual Data Link Control (VDLC) for two primary connectivity options:

Transport over DLSw+ supported media

Data link control local switching support for access to Synchronous Data Link Control (SDLC) and Qualified Logical Link Control (QLLC)

Usability, Serviceability, and Management

SNASw includes a number of features designed to improve its usability, serviceability, and management.

Dynamic Control Point Name Generation Support

When scaling the SNASw function to hundreds or thousands of nodes, many network administrators find that defining a unique control point (CP) name on each node provides unnecessary configuration overhead. Dynamic CP name generation offers the ability to use the Cisco IOS host name as the SNA CP name or to generate a CP name from an IP address. These facilities reuse one SNASw configuration across many routers and eliminate the specific configuration coordination previously required to configure a unique CP name for each SNA node in the network. However, the ability to explicitly configure each CP name still exists.

Dynamic SNA Basic Transmission Unit Size

Most SNA node implementations require specific tuning of the SNA basic transmit unit (BTU) in the configuration. SNASw analyzes the maximum transmission unit (MTU) size of the router interfaces it uses and dynamically assigns the best MTU values for that specific port. For served dependent PU 2.0 devices, SNASw uses the downstream MAXDATA value from the host and then dynamically sets the SNA BTU for that device to the MAXDATA value.

DLUR Connect-Out

SNASw can receive connect-out instructions from the IBM CS/390 (DLUs). This function allows the system to dynamically connect-out to devices that are configured on the host with the appropriate connect-out definitions. This feature allows connectivity to SNA devices in the network that were traditionally configured for connect-out from the host.
Note: DLUR connect-out can be performed over any supported data link type.

User Control of Port Limits

SNASw offers full load limiting control over the number of downstream devices (links) supported by a SNASw router. This SNASw configuration capability can control the number of devices that are serviced by this node. When the maximum number of devices is reached, SNASw no longer responds to explorers attempting to establish new connections. This allows SNASw to share the load among different SNASw nodes that offer service to the same SNA MAC addresses.

Console Message Archiving

Messages issued by SNASw are archived in a problem determination log that is queried and searched on the console or transferred to a file server for analysis. Each message has a single line that identifies the nature of the event that occurred. The log also maintains more detailed information about the message issued.

Data Link Tracing

SNA frames entering or leaving SNASw are traced to the console or to a cyclic buffer. These frames are analyzed at the router or can be transferred to a file server for later analysis. The trace can be sent to a file server in an SNA-formatted text file or in binary format readable by existing traffic analysis applications. SNASw also can capture record frames natively, eliminating the need for network analyzers to capture network events for analysis.

Interprocess Signal Tracing

The SNASw internal information is traced in binary form, offering valuable detailed internal information to Cisco support personnel. This information helps diagnose suspected defects in SNASw.
Note: This trace should only be used when requested by Cisco Technical Assistance Center (TAC) or Development Engineering support.

Trap Management Information Base Support for Advanced Network Management Awareness

SNASw supports the APPN Trap Management Information Base (MIB) (RFC 2456), which proactively sends traps with information about changes in SNA resource status. This implementation reduces the frequency of Simple Network Management Protocol (SNMP) polling that is necessary in order to manage SNA devices in the network. SNASw also supports the standard APPN MIB (RFC 2455) and the standard DLUR MIB (RFC 2232).
1 APPN Branch Extender Architecture Reference (SV40-0129)

[an error occurred while processing this directive]