[an error occurred while processing this directive]

IBM SNA Networking

Cisco SNA


Technology Brief


Cisco Technology Brief

Systems Network Architecture (SNA), IBM's proprietary networking architecture, was first introduced in 1974. SNA has reached a position of prominence in the computer industry based on its completeness and its continued support by IBM. SNA's architecture was a primary basis for the OSI Reference Model, which was created a decade after SNA's introduction.

Over the years, SNA has been expanded to accommodate evolution in computer networking. Originally an extremely hierarchical architecture designed especially for terminal-to-host communications, SNA has evolved to include support for peer-to-peer networks as well as certain standardized network media and protocols.

SNA continues to evolve and is expected to remain a fixture in network technology for years to come.

This technology brief summarizes SNA technology and analyzes Cisco System's value-added SNA features. Knowledge of networking fundamentals is assumed.

SNA and the OSI Reference Model

The SNA architectural model is closely aligned with the OSI -Reference Model. The two models are shown in Figure 1.

Figure 1.: SNA and OSI Reference Models

SNA does not define specific protocols for its physical control layer, because IBM assumed that this layer would be implemented with various international standards. SNA's data link control layer defines several protocols, including the Synchronous Data Link Control (SDLC) protocol for hierarchical communication and the Token Ring Network communication protocol for local area network (LAN) communication between peers. For more information on SDLC, refer to Cisco's SDLC Transport protocol brief. For more information on bridging concepts in general, refer to Cisco's Bridging technology brief.

The SNA path control layer performs many OSI network layer functions, including routing and datagram segmentation and reassembly (SAR). The SNA transmission control layer provides a reliable end-to-end connection service, as well as encryption and decryption services. SNA's data flow control layer controls request and response processing, determines whose turn it is to communicate, groups messages together, and can interrupt data flow on request. The SNA presentation services layer specifies data transformation algorithms that translate data from one format to another. The presentation services layer also coordinates resource sharing and synchronizes transaction operations. Finally, the SNA transaction services layer provides application services in the form of programs that implement distributed processing or management services.

In addition to the seven layers just discussed, SNA terminology includes an additional phrase that further describes portions of its layered architecture. The SNA path control network is responsible for moving information between SNA nodes. When these nodes are on different networks, the path control network attempts to ensure that the communicating entities believe they are talking to nodes on their own networks. The path control network consists of SNA's path control and data link control layers, and is a subset of the SNA transport network.

SNA Components

SNA networks consist of nodes and links. Nodes are network components that contain host protocol implementations; links are transmission facilities that carry data between two SNA nodes. The term "link" also assumes the ability for the two -connected nodes to operate a data link control procedure between them.

Traditional SNA communication involves four separate physical entities:

  • Hosts. Hosts control all or part of a network. They provide computation, program execution, data base access, directory services, and network management.

  • Front-end processors. Front-end processors (now often called communication controllers) manage the physical network, control communication links, and route data through a network.

  • Cluster controllers. Cluster controllers (now often called establishment controllers) control input and output operations of devices attached to them.

  • Terminals. Terminals (sometimes called workstations) provide the user interface to the network.

SNA offers support for a variety of data link control techniques, including the following:

  • Mainframe channels. IBM hosts are connected to each other and to front-end processors through high speed (3 - 4.5 megabyte per second), parallel-data channels that use direct-memory-access data-movement techniques. These channels use multiwire cables and can be up to several hundred feet in length. IBM also supports a newer serial-data channel (Enterprise Systems Connection, or ESCON), which offers higher speed (18 megabytes per second) and greater range (several kilometers). ESCON uses optical fiber as the network medium.

  • SDLC. IBM front-end processors are usually connected to each other and to establishment controllers via SDLC links. SDLC is a bit-synchronous IBM data link control protocol allowing movement of data via telecommunications links. Many other popular bit-synchronous protocols were derived from SDLC, including High-Level Data Link Control (HDLC) and Link Access Protocol Balanced (LAPB).

  • X.25. X.25 networks between two SNA nodes are treated as a single link, with X.25 as the access protocol. However, although the two SNA nodes are considered to be adjacent to one another, they require certain data link control protocol capabilities which X.25 does not provide. SNA offers several specialized data link control protocols (Physical Services Header, Qualified Logical Link Control [QLLC], and Enhanced Logical Link Control [ELLC]) that offer these data link control protocol capabilities, allowing SNA to run effectively over X.25 networks.

  • Token Ring Network. The Token Ring Network is SNA's primary data link control method for LANs. IBM's Token Ring Network is -virtually the same as the IEEE 802.5 link access protocol running under the IEEE 802.2 logical link control Class II protocol (often referred to as LLC2). LLC2 links are characterized by their connection-oriented nature.

More recently, IBM has added support for Ethernet, FDDI, frame relay, and other media access protocols.

Whereas nodes and links are the physical embodiment of the SNA architecture, network addressable units (NAUs) are the logical users of SNA's transport network. NAUs communicate with one another through sessions. There are three primary NAU types:

  • Logical units (LUs). LUs function as end-user access ports into the network, providing users with access to network resources and managing the transmission of information between end users. Nodes may have multiple LUs. A variety of LU types exist, including LU Types 0, 1, 2, 3, 4, 6.1, 6.2, and 7.

  • Physical units (PUs). PUs monitor and control attached network links and other network resources associated with a particular node. SNA access methods implement PUs on hosts, while network control programs implement PUs on front-end processors. Several PU types exist, including PU Types 2, 2.1, 4, and 5.

  • Control points (CPs). CPs manage nodes and their resources. They are differentiated from PUs in that they determine which actions must be taken, whereas PUs cause the actions to actually occur. A CP residing in a PU Type 5 node is called a system services control point (SSCP). SNA access methods such as IBM's Virtual Telecommunications Access Method (VTAM) implement SSCPs.

SNA nodes are assigned to one of two categories:

  • Subarea nodes. Subarea nodes provide all network services, including intermediate routing and address mapping between local and network-wide addresses. Node types 4 (T4) and 5 (T5) are subarea nodes. Although there is no relationship between SNA node types and actual physical entities, T5 nodes are usually contained in hosts, and T4 nodes are usually contained in front-end processors. VTAM is an example of a T5 node. VTAM controls the logical flow of data through a net-work, provides an interface between application subsystems and a network, and protects application subsystems from unauthorized access. IBM's Network Control Program (NCP) is an example of a T4 node. NCP routes data and controls its flow between the front-end processor and other network resources.

  • Peripheral nodes. Peripheral nodes use only local addressing and communicate with other nodes through subarea nodes. Node types 1 (T1) and 2 (T2) are examples of peripheral nodes. T1 nodes (now obsolete) reside in unintelligent terminals; T2 nodes typically reside in intelligent terminals or establishment controllers.

Traditional SNA components are typically organized as depicted in Figure 2.

Figure 2.: Traditional SNA Network

SNA networks are divided into logical areas. A subarea, which is comprised of a subarea node and its attached peripherals, is an example of a logical network. A domain consists of a SSCP and the network resources that it can control. SSCPs in different domains can cooperate with one another to compensate for host processor failures. Figure 3 illustrates the concepts of subareas and domains.

Figure 3.: Subareas and Domains

SNA Peer-to-Peer Communications

In the years following SNA's introduction in 1974, the computer industry began to migrate from a centralized, hierarchical approach utilizing large mainframes toward a distributed approach utilizing groups of smaller, less expensive, networked computers. With the introduction and subsequent acceptance of microcomputers into the business community in the early 1980s, this migration reached new heights. A new type of network, the peer-to-peer network, emerged.

Peer-to-peer networks consist of computers with similar network capabilities that can essentially address one another as peers.

IBM responded to the trend toward peer-to-peer networking with the introduction, over a period of years, of several new concepts allowing peer-to-peer networking in SNA environments. These concepts, which have become integral to today's SNA networks, include the following:

  • LU 6.2. LU 6.2 is a type of LU that supports communication between two applications in a distributed data processing environment. It supports communication between dissimilar as well as similar node types. For example, communication between a T5 and a T2.1 node is supported, as is communication between two T2.1 nodes.

  • Advanced Program-to-Program Communications (APPC). APPC is a set of programming conventions and protocols that implement LU 6.2. APPC is the name given to the LU 6.2 capability in products that implement this LU type.

  • PU 2.1. PU 2.1 is a specific PU type that, unlike PU 2.0, allows direct communication with other peripheral nodes (that also support PU 2.1). PU 2.1 nodes facilitate point-to-point communications by providing data transport support for peer-level communications supported by APPC/LU 6.2. A PU 2.1 node contains a Peripheral Node Control Point (PNCP), which is a combination of the traditional PU and CP. The PU 2.1 is now referred to as Node Type (NT) 2.1, or simply T2.1.

  • Advanced Peer-to-Peer Networking (APPN). APPN is an IBM architecture supporting peer-to-peer communications, directory services, and routing between two or more APPC systems that are not directly attached. APPN distinguishes between network nodes (NNs) and end nodes (ENs). NNs contain a CP in their path control layer. This allows intermediate routing and distributed name resolution within T2.1 nodes. ENs also contain a CP, but the EN CP does not provide as much functionality as the NN CP.

An APPN SNA network is illustrated in Figure 4.

Figure 4.: APPN SNA Network

SNA Routing Concepts

Subarea node addressing differs from peripheral node addressing. Subarea addresses are global and must be unique within the entire network. Subarea addresses are assigned to NAUs when they are activated. Subarea addresses generally consist of two parts: a subarea and an element. The subarea portion identifies the subarea within the network, while the element portion identifies the element within the subarea. All NAUs within a given subarea share the same subarea address but have different element addresses.

Peripheral node addresses differ depending on whether the node is a T2 or a T2.1 node, but in both cases they are local addresses. T2 addresses refer to NAUs and are statically assigned. T2.1 addresses are dynamically assigned for the duration of a session and identify the session rather than the NAU. They are referred to as local form session identifiers.

When sessions traverse multiple address spaces, a session connector component is used to bridge the address spaces where they meet. SNA's three types of session connectors are:

  • Boundary functions. Boundary functions reside in subarea nodes and map between subarea and peripheral address spaces.

  • SNA network interconnect (SNI) gateways. SNI gateways act as the bridge between SNA networks, accepting data from one network and transmitting it to the appropriate destination in another network. SNI gateway operations are transparent to end-point NAUs.

  • APPN intermediate routing functions. APPN session connectors perform intermediate routing within APPN networks.

As with any network, directory services are used to map SNA network resources to locations. SNA locations are identified by address (in a subarea network) or by the control point name (in T2.1 nodes). LUs in peripheral nodes can be located by the subarea address of the attached subarea. Directory services are provided by SSCPs (for resources in both T5 and T4 subareas) and T2.1 CPs (for APPN nodes).

Within APPN networks, APPN nodes simply broadcast queries to all neighbors. When a query reaches a node with the requested resource, it sends a positive response back to the node from which it received the request. Crossed queries are interpreted as a negative reply by both nodes. End-node resources may be learned either through static assignment or through registration with the appropriate network node.

SNA session traffic travels a fixed path through the SNA network. Paths are constructed over transmission groups, which are logical connections between adjacent SNA nodes. Transmission groups, often referred to as TGs, are composed of one or more SNA link(s) and the transmission priorities assigned to them.

Multilink TGs are used to bundle multiple physical links into a single logical SNA link. Traffic directed to a particular TG can traverse any of the physical links included in that TG, thereby providing extra reliability (because link failures can be compensated for) and bandwidth (because any link in the group can be used for transmission). TG sequence numbers are used to resequence out-of-order messages at each hop. Four transmission priorities are supported at each transmission group: low, medium, high, and Network Services Traffic (the highest priority). Multilink TGs are only supported between T4 nodes.

Routes between subareas may be explicit or virtual. Explicit routes are physical connections between two subarea nodes, and are defined as an ordered sequence of subareas and connecting TGs. Since explicit routes are unidirectional, two (one in each direction) are required to create a full duplex path. Virtual routes are two-way logical connections between two subarea nodes. A given virtual route is said to flow over an explicit route and the reverse explicit route that follows the same physical path. Virtual routes do not cross network boundaries. When network interconnection is required, a SNA network interconnect session connector bridges the two virtual routes. Virtual routes also include values that define transmission priority and global flow control parameters. Global flow control is provided by pacing, a technique where a receiver with sufficient buffer space grants pacing windows to the sender. Each pacing window allows the sender to transmit a certain amount of information before the sender must request the next pacing window.

Components of SNA routing are illustrated in Figure 5.

Figure 5.: Components of SNA Subarea Routing

Routing between T2.1 nodes occurs between one or more intermediate APPN nodes. Each APPN intermediate node contains a session connector to bridge between the two path controls. The session connector uses a different local form session identifier on each TG it couples and, therefore, swaps the appropriate values into the transmission header at each hop. Flow control in APPN is also handled on a TG by TG basis. Global flow control is produced by back pressure, where pacing window reductions by end nodes pro-voke intermediate nodes to reduce their window sizes, which eventually affects the transmission rate of the source end node.

All SNA routes are chosen based on class of service (COS). Class of service is a definition of acceptable service levels for a particular session. It is defined by characteristics such as response time, security, and availability, and is specified either automatically at logon or manually (by the user) when a session is initiated. Each COS name is associated with a list of virtual routes that the network administrator has decided will meet the desired service level requirement. From that list, an available virtual route is chosen. In subarea routing, the user defines classes of service, the virtual routes they map to, and the TGs that the underlying explicit routes traverse.

In APPN, routing is dynamic and is based on a least-weight path calculated from input received from all APPN network nodes. Each APPN network node is responsible for reporting changes in its local topology (that is, the node itself and the attached links). Topology information is passed until all APPN nodes have received it. When a node receives data it already has, it stops forwarding the data to other nodes. Duplicate information is recognized via a check of update sequence numbers.

Bridging in SNA LANs

Token Ring and IEEE 802.5 LANs are bridged via a technique called Source-Route Bridging (SRB). In SRB, an optimal path is chosen by exploring all possible paths and selecting one based on a predetermined criterion. That path is then used for all traffic from the originator to the destination for the duration of the session.

Ethernet and IEEE 802.3 LANs use Transparent Bridging (TB), a technique which is incompatible with SRB. Bridges running the TB algorithm learn the network's topology through association of a frame's source address and the line on which the frame was received. Frames are forwarded one hop at a time. Because many of today's large enterprise networks include both IEEE 802.3 and IEEE 802.5 LANs, the problem of how to bridge between SRB and TB environments is a potentially serious one.

One technique used to solve the SRB/TB bridging problem is Translational Bridging (TLB). TLB translates between the two bridging techniques. TLB is used in IBM's 8209 product, which acts like a transparent bridge on the Ethernet side and like a source-route bridge on the Token Ring side.

Due to certain limitations with the TLB algorithm, IBM has proposed another technique for solving the SRB/TB bridging problem. This technique is referred to as Source-Route Transparent (SRT) bridging. SRT bridges essentially run both the TB and the SRB algorithms. When a frame enters the bridge, the bridge checks to see whether the frame is a SRB or a TB frame, employs the correct algorithm, and sends the frame out the appropriate port.

For more information on bridging algorithms, refer to Cisco's Bridging technology brief.

SNA Network Management

NetView is SNA's primary network management architecture. Introduced in 1986, NetView operates by providing a cohesive set of centralized network management services that allow users to monitor, control, and reconfigure their SNA networks. SNA nodes send alerts when they recognize problems. These alerts are picked up and logged by NetView. In addition, NetView can, through user commands, send configuration commands to SNA nodes.

IBM also provides NetView service point, an interface into NetView designed for non-SNA equipment. NetView/PC is a well-known product that implements the NetView service point. Through the NetView service point interface, third party products can send alerts up to NetView and be directed by NetView commands.

IBM's LAN Network Manager (LNM) product is an OS/2 Extended Edition-based network management product for Token Ring networks. It is designed to manage large, multisegment LAN sites in situations where both local and centralized control are needed. LNM can manage up to 65 Token Ring segments and can itself be managed by NetView.

Cisco Systems' SNA Support

Cisco offers a diverse set of hardware and software features designed to support basic SNA functionality. In addition, Cisco's SNA solution integrates SNA networks with non-SNA networks in the following ways:

  • Integrating SNA technology and products with multiprotocol, multimedia enterprise networks

  • Integrating SNA point-to-point technologies with multi-access technologies

  • Integrating SNA terminal-to-host technologies with peer-to-peer technologies

These features are described in the following sections.

Cisco Systems' SNA Hardware Support

Cisco offers a complete line of multimedia, multiprotocol router hardware platforms. These routers form the foundation of Cisco's SNA support. For more information on Cisco's routers, refer to various Cisco product briefs describing these hardware platforms and their capabilities.

To support Token Ring networks, Cisco offers several Token Ring interface cards that can be installed in Cisco's modular routers. These interface cards support both 4-and 16-megabit-per-second (Mbps) rings, and provide one, two or four Token Ring ports on a single interface. Cisco's modular Token Ring board supports the IBM chipset and utilizes a driver co-authored with IBM. This board has achieved Token Ring wire speeds for large packets and is faster than any other Token Ring board currently on the market. In addition to Token Ring support for its modular routers, Cisco's fixed-configuration routers provide Token Ring support in combination with a high-speed serial line, for access to remote Token Rings.

All Cisco serial interface cards support SDLC. Cisco provides both low-speed and high-speed serial communication cards. The high-speed cards support line speeds of up to 4 Mbps. Although SDLC links often operate at 9.6 Kbps, Cisco-supported SDLC links can be configured at 64 Kbps (for connection to IBM 3174 establishment controllers) or T-1 (for connection to IBM 3745 front-end processors).

Cisco Systems' SNA Software Support

Cisco customers have indicated their desire for Cisco SNA support to enhance the availability, performance, flexibility, reliability, and manageability of their SNA networks. To that end, Cisco's SNA software support includes the following features:

  • SDLC transport

  • SRB/RSRB support

  • Multimedia technologies

  • Wide-area network (WAN) optimization features

  • PU Type 4 properties

  • Multiprotocol network management

Each of these features is now discussed individually, with attention to how each feature enhances customer SNA networks.

Cisco's SDLC transport feature provides customers with a way to seamlessly integrate traditional SNA networks with non-SNA environments. Figure 6 shows a typical mixed-vendor environment, with traditional SNA equipment on the left and a common remote LAN interconnection environment on the right. The depicted traditional SNA environment has several limitations. First, the 19.2 kilobit per second (Kbps) leased-line solution is too slow. Second, this leased-line solution offers limited backbone media and access method options. For example, it cannot support offshoots to FDDI, Ethernet, or Token Ring LANs. Third, it is basically a pass-through, link-layer environment. Even if additional media interfaces were present, intelligent routing using today's advanced routing protocols could not be done. Finally, integration with the remote LAN interconnection environment is not achieved.

Figure 6.: Typical Mixed-Vendor Network Configuration

Figure 7 shows the same mixed vendor environment after integration using Cisco equipment. The two separate networks have been integrated into a single high-speed enterprise-wide network, saving network connections and providing enhanced connectivity. Cisco routers can pass both native SDLC traffic and other protocol traffic over these links. SDLC frames can also be encapsulated in IP datagrams for transport over arbitrary (non-SDLC) networks. When this occurs, powerful IP-based routing protocols such as Cisco's IGRP protocol can be used. IGRP supports automatic switching to backup links, load sharing (through dual-link multiplexing), and security (through access lists, which can prevent frames matching certain characteristics from reaching specified networks). All Cisco media options (including FDDI, Token Ring, Ethernet, X.25, Frame Relay, SMDS, and T-1/T-3) are supported.

Figure 7.: Cisco-Based SDLC Transport Solution

Cisco's SDLC transport solution supports priority output queuing. Using this capability, protocol traffic through a Cisco router can be prioritized to suit specific situations. For example, automated teller machine (ATM) traffic can be prioritized ahead of less important traffic. In this fashion, Cisco's priority output queuing allows preservation of SNA's native COS prioritization, ensuring timely delivery of critical SNA information.

Finally, Cisco's SDLC transport solution provides a virtual multipoint capability that saves money and provides enhanced security. An address-mapping capability ensures that SDLC frame addresses are properly associated with destination establishment controllers. Cisco routers then send each frame over the best path to that controller. This allows a front-end processor to communicate with multiple establishment controllers from a single serial link across an arbitrary network topology. Cost savings accrue from efficient use of serial links. Enhanced security results from restricted access based on SDLC address.

Cisco's SRB solution offers cost effectiveness through higher port density. Higher port density also increases overall system performance over cascaded solutions, where extra time is required to traverse multiple physical bridges. Cisco's "interconnectivity hub" solution reduces hop counts and transit delays, while simplifying network design and maintenance.

Cisco introduced the concept of a virtual ring with its SRB feature. The virtual ring is represented by a logical ring number associated with an arbitrary topology network that bridges multiple Token Rings attached to one or more Cisco router/bridges. Cisco's SRB algorithm uses the logical ring number as if it was a physical ring number, and assumes that the logical ring will take one additional hop to transit. Within the virtual ring, routing can occur. The virtual ring simplifies network topology, assists in the building of large-scale networks (because it hides multiple hops), provides intelligent path selection (because routing within the ring can occur), and reduces explorer traffic (because explorer frames within a virtual ring are not exponentially duplicated). Figure 8 illustrates the logical ring concept.

Figure 8.: Cisco Virtual Ring

Cisco's SRB offering can further reduce explorer traffic through the use of proxy explorers. Cisco routers maintain a cache containing end node location information. When a Cisco router receives an explorer packet indicating a search for a node that the router knows about (that is, the router has an entry for the node in its cache), it replies on behalf of the destination node. Explorer packets need not travel through the network. Proxy explorers are most useful in meshed networks linked by serial lines. Cisco routers can eliminate potential explorer congestion problems and expedite the route discovery process in virtually any situation.

Cisco also supports a variety of intermedia connection technologies, including SRT, TLB, and SDLLC. For optimal flexibility, each of these features is provided in all Cisco routers.

Cisco's SRT and TLB facilities offer solutions to the problem of communicating between SRB and TB environments. Cisco's SRT feature is 100% compatible with the IEEE 802.1 SRT draft standard, ensuring interoperability between Cisco SRT and other products that are SRT-compliant. Cisco's TLB solution is completely interoperable with existing transparent bridges and source-route bridges.

Cisco's SDLLC feature solves the problem of communication between traditional SNA environments using SDLC and SNA LAN environments using LLC2. Traditionally, the only way to connect these two environments has been through front-end processors or 3174 Token Ring gateways. Because these solutions have had limited appeal in many networks (due to cost or support environments), a number of older SNA devices are not able to communicate with Token Ring devices. Cisco's SDLLC feature solves this problem by performing the necessary media and protocol conversion to allow seamless communication between SDLC and LLC2 end nodes. End nodes on both sides believe they are communicating with like devices.

Figure 9 shows a typical SDLLC configuration where SDLC and LLC2 end nodes are connected by Cisco routers communicating over a WAN of arbitrary topology. Cisco's SDLLC software need only be enabled in the routers on the SDLC sides of the communication (Routers B and C).

Figure 9.: Typical SDLLC Configuration

In WAN configurations such as in Figure 9, IP encapsulation is used to send frames between Cisco routers at the periphery of and within the internetwork "cloud." Use of IP at the network layer permits dynamic routing, load sharing, and redundancy in media-independent environments.

The Cisco SDLLC solution solves other SNA connectivity problems. For example, it reduces the required number of serial ports and automatically fragments and reassembles Token Ring frames. In general, SDLLC addresses all three types of integration introduced at the beginning of this section ("Cisco Systems' SNA Support"). For more detail on SDLLC, refer to the Cisco SDLLC Protocol Brief.

Cisco's software for SNA environments offers several ways to optimize WANs connecting SNA nodes. Since WANs often operate at speeds one or two orders of magnitude lower than that of LANs, WANs are frequently the bottleneck in enterprise communication. Optimizing WAN performance, therefore, has a direct impact on user response times and (because WAN links are often leased based on utilization parameters) on cost. In addition to WAN performance, WAN media and topology limitations may also pose a problem. Cisco's solutions to traditional SNA WAN problems include the following:

  • Local session termination

  • IP encapsulation

  • Header compression

  • Support for fast WAN technologies

Local session termination provides a way for Cisco routers to locally terminate both SDLC and LLC2 data link control sessions at each communicating end. So, instead of end-to-end sessions where all session control information is passed over the WAN between end nodes, Cisco routers at the LAN/WAN border can take responsibility for acknowledgment of packets coming from hosts on directly-attached LANs. Figure 10 shows how local acknowledgment works between two LLC2 stations. SDLC session termination works in a similar fashion.

Figure 10.: Cisco's Local Session Termination Feature

In addition to saving WAN bandwidth (and, therefore, WAN utilization costs), local session termination also provides faster response times to users. Faster response times are realized because acknowledgments no longer have to traverse the WAN, where long link delays may occur.

Finally, local session termination solves SDLC and LLC2 time-out problems. These two protocols rely on session timers to determine when a session should be timed out (based on the absence of messages from the other communicating node). Although the protocols allow network administrators to set this timer, many SNA devices do not offer configuration options. Moreover, WANs are often dynamic environments where large variations in response times can occur. If the timeout interval is set too low, timeouts may occur in situations where there is really no circuit problem other than normal delays. If the timeout value is set too high, nodes may not recognize circuit failures quickly enough. With local session termination, however, the router can provide acknowledgments immediately, with very predictable delay. Timeout values can be set with a high degree of confidence.

Cisco offers various encapsulation schemes which change the very nature of the SNA WAN. TCP/IP encapsulation is used for local acknowledgment situations, sequenced IP is used for transmission over an arbitrary backbone, and direct encapsulation is available for point-to-point connections.

By encapsulating SDLC and LLC2 frames into IP packets, TCP/IP's transport and routing capabilities can be used to move SNA traffic over the WAN. In so doing, a homogeneous collection of slow-speed serial links requiring individual connections to each device is replaced by a general mesh topology capable of superior throughput, reliability, and diversity. Compatibility issues surrounding the underlying media technologies are rendered unimportant, because IP runs above the data link control level. Information can be routed intelligently through the WAN using Interior Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), or other powerful IP routing protocols. In addition to these benefits, Cisco TCP/IP encapsulation also provides support for multiprotocol traffic, dynamic load sharing, and automatic recovery from link failure.

Since TCP/IP encapsulation adds about 40 bytes to each SNA frame, Cisco provides optional header compression using the Van Jacobson algorithm (as documented in Internet specification RFC 1144). Use of the Van Jacobson algorithm can reduce IP headers from 40 to about 3 to 8 bytes, thereby saving WAN bandwidth and (potentially) money.

Sequenced IP is an enhanced IP implementation that orders upper-layer messages submitted to IP so that they can be delivered to the destination in the proper order. Normally, TCP would perform packet sequencing, but TCP's transmission overhead associated with reliable delivery may be unacceptable in some situations. Sequenced IP is designed to address those situations where TCP's level of reliability is not necessary.

Direct encapsulation using HDLC is useful in situations where control overhead must be minimized. Since HDLC's overhead is typically only about 1% of total bandwidth, HDLC can be used on low-bandwidth, point-to-point links. In addition to minimal control traffic overhead, HDLC also has a minimal effect on CPU utilization.

Finally, WAN technologies have progressed significantly in the recent past. New high-performance WAN protocols such as High-Speed Serial Interface (HSSI), Frame Relay, SMDS, and others close the performance gap between LANs and WANs considerably. Cisco supports HSSI, Frame Relay, and SMDS, and will continue to support each important new WAN technology in a timely fashion. Faster WANs allow the extension of delay-critical LAN applications into an enterprise environment, thereby significantly increasing the network's utility to the end user.

Because many SNA networks support real-time, transaction-based applications (such as point-of-sale and automated tellers), reliable networks with predictable response times are critical to SNA's success. SNA's designers have therefore included provisions supporting traffic prioritization (COS) and path flexibility (TG). Cisco emulates these PU Type 4 properties.

Cisco routers recognize both the network priority bit and the transmission priority field in SNA Format Identification 4 (FID4) headers and prioritize packets accordingly. One of four prioritized TCP/IP connections is used to transmit the information. Cisco's priority output queuing mechanism, coupled with its facility for local termination, support this function. Figure 11 illustrates Cisco's COS support.

Figure 11.: Cisco's COS Facility

Cisco software not only recognizes priorities between IBM FEPs, but also allows different LU addresses to have different priorities, which can then be reflected up to FEPs. In retail environments, this facility can be used to allow credit card verification to be performed before inventory transfers.

Cisco's TG support enhances network reliability (through link redundancy) and network performance (through load-sharing). Both multi-link SDLC and single-link Token Ring connections between FEPs are supported. Further, any transmission group can be represented physically by an arbitrary-topology Cisco multiprotocol backbone. The Cisco internetwork carries a TG as a single logical entity from one front-end processor to another. Packets transmitted on TGs are numbered so that resequencing and TG sweeping (scanning TGs) can be handled properly, thereby preserving the integrity of the TG.

Cisco provides support for IBM's critical network management facilities (NetView and LNM). Cisco routers can communicate with NetView via a NetView-to-SNMP gateway working in conjunction with SunNetwork Manager. An example is shown in Figure 12.

Figure 12.: Network Functionality

Cisco's support for LNM allows Cisco routers to relay LNM queries to other rings and to be managed as if they were IBM bridges. NetView visibility is achieved through the Service Point interface between LNM and NetView.

Cisco routers support the SNMP Management Information Base (MIB) for Token Ring as well as SRB elements of the draft SNMP MIB for bridging. These features allow SNMP and NetView users much more visibility into their merged networks.

Cisco has also created CiscoWorks, a series of applications for managing, administering, and monitoring Cisco internetworks. CiscoWorks applications are divided into two categories, based on network personnel job functions: operations series and management series. Operations series applications are designed to address the day-to-day tasks associated with router monitoring, troubleshooting, and administration. These applications simplify and automate time-consuming administrative tasks by allowing network analysts and operators alike to easily analyze and monitor paths, and to monitor the status and health of the routers. In contrast with operations series applications, which are focused on day-to-day tasks, management series applications facilitate off-line analysis of network traffic patterns and trends.


Now more than ever, enterprise networks are being driven by end-user applications. Today's rapidly-changing business computing environment demands a diverse set of client-server applications that operate over a variety of LANs and WANs. -Multiprotocol, multimedia internetworks are the inevitable manifestations of this trend.

Cisco Systems' SNA solutions focus on integration and compatibility. Using Cisco products, IBM's traditional SNA networks are augmented and integrated with the diverse internetworks found in most current businesses. This not only addresses many of the issues associated with traditional SNA communications, it also opens the world of multivendor communications to the IBM user.


Berson, Alex. APPC: Introduction to LU6.2, New York, NY: McGraw-Hill, Inc.; 1990.

Cisco Systems, Inc. Bridging. Technology Brief. Menlo Park, CA; 1992.

Cisco Systems, Inc. Internetworking IBM Environments. Statement of Direction. Menlo Park, CA; 1992.

Cisco Systems, Inc. SDLC Transport. Protocol Brief. Menlo Park, CA; 1991.

Cisco Systems, Inc. SDLLC (SDLC to LLC2 Translation). Protocol Brief. Menlo Park, CA; 1992.

Cisco Systems, Inc. Source-Route Bridging. Protocol Brief. Menlo Park, CA; 1991.

IBM Corporation. Systems Network Architecture. Research Triangle Park, NC; 1986.

Kharbadar, Percy. "Cisco Routers Support Local Acknowledgment for Token Ring Interfaces." The Packet, Vol. 3, No. 4: Winter; 1992.

Martin, James. SNA: IBM's Networking Solution. Englewood Cliffs, NJ: Prentice-Hall, Inc.; 1987.

Sunshine, Carl A. ed. Computer Network Architectures and -Protocols. New York, NY: Plenum Press; 1989

[an error occurred while processing this directive]