|
|
The IBM networking technologies described in this publication can be categorized as network-related or host-related technologies. The IBM Networking section of the Cisco IOS Bridging and IBM Networking Configuration Guide discusses the following network-related software components:
The IBM Networking section of the Cisco IOS Bridging and IBM Networking Configuration Guide discusses the following host-related software and hardware components:
This overview chapter gives a high-level description of each technology. For configuration information, refer to the corresponding chapter in this publication.
 |
Note All commands supported on the Cisco 7500 series routers are also supported on the Cisco 7000 series routers. |
In contrast to Source-Route Bridging (SRB), which involves bridging between Token Ring media only, RSRB is Cisco's first technique for connecting Token Ring networks over non-Token Ring network segments. (DLSw+ is Cisco's strategic method for providing this function.)
Cisco's RSRB software implementation includes the following features:
Figure 85 shows an RSRB topology. The virtual ring can extend across any non-Token Ring media supported by RSRB, such as serial, Ethernet, FDDI, and WANs. The type of media you select determines the way you set up RSRB.
|
Note If you bridge across Token Ring media, it is recommended that you do not use RSRB. Use SRB instead. Refer to the chapter "Configuring Source-Route Bridging." |
Use IP encapsulation only over a TCP connection within complex meshed networks to support connections between peers that are separated by multiple hops and can potentially use multiple paths, and where performance is not an issue. Use direct encapsulation in point-to-point connections. In a point-to-point configuration, using TCP adds unnecessary processing overhead. Multiple peer types, however, can be combined to in a single router by following the directions for each peer type. For example, for a peer to support both TCP and FST remote-peers, you would need to define both a source-bridge fst peername and a source-bridge remote-peer command for the local router, using the same local IP address.
In cases where FST is fast-switched, in either the Cisco routers configured for FST or in the routers contained within the IP "cloud" between a pair of FST peers, only one path is used at a given time between the two FST peers. A single path greatly decreases the likelihood that frames arrive out of sequence. In the rare cases where frames do arrive out of sequence, the FST code on the receiving peer discards the out-of-order frame. Thus the Token Ring end hosts rarely lose a frame over the FST router cloud, and performance levels remain adequate.
The same conditions are true for any slow-switched topology that provides only a single path (for example, a single X.25 network cloud) between the peers. Similarly, if two slow-switched paths are of very different costs such that one always will be chosen over the other, the chances of having frames received out of sequence are also rare.
However, if two or more slow-switched paths of equal cost exist between the two routers (such as two parallel X.25 networks), the routers alternate in sending packets between the two or more equal-cost paths. This results in a high probability of frames arriving out of sequence at the receiver. In such cases, the FST code disposes of every out-of-sequence packet, leading to a large number of drops. This requires that the end hosts retransmit frames, greatly reducing overall throughput.
When parallel paths exist, we strongly recommend choosing one as the preferred path. Choose a preferred path by specifying a higher bandwidth for the path that contains the direct connections to the two or more parallel paths on the router.
Do not use FST when the probability exists for frames to lose their order in your network. If you have a network where frames are routinely reordered, it is better to use the TCP protocol for RSRB. TCP provides the overhead necessary to bring frames back in order on the receiving router. FST, to remain fast, does not provide for such a mechanism, and will discard out-of-order frames.
Logical Link Control, type 2 (LLC2) local acknowledgment can be enabled only with TCP remote peers (as opposed to LAN or direct serial interface remote peers) because the Cisco IOS software needs the reliable transmission of TCP to provide the same reliability that an LLC2 LAN end-to-end connection provides. Therefore, the direct media encapsulation options for the source-bridge remote-peer command cannot be used.
If the LLC2 session between the local host and the router terminates on either side of the connection, the other device will be informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two routers reaches 90 percent of its limit, they send Receiver-not-Ready (RNR) messages to the local hosts until the queue limit is reduced to below this limit.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall performance. Refer to the "Configuring LLC2 and SDLC Parameters" chapter for more details about fine-tuning your network through the LLC2 parameters.
|
Note As previously stated, local acknowledgment for LLC2 is meant only for extreme cases in which communication is not possible otherwise. Because the router must maintain a full LLC2 session, the number of simultaneous sessions it can support before performance degrades depends on the mix of other protocols and their loads. |
The routers at each end of the LLC2 session execute the full LLC2 protocol, which can result in some overhead. The decision to turn on local acknowledgment for LLC2 should be based on the speed of the backbone network in relation to the Token Ring speed. For LAN segments separated by slow-speed serial links (for example, 56 kbps), the T1 timer problem could occur more frequently. In such cases, it might be wise to turn on local acknowledgment for LLC2. For LAN segments separated by a FDDI backbone, backbone delays will be minimal; in such cases, local acknowledgment for LLC2 should not be turned on. Speed mismatch between the LAN segments and the backbone network is one criterion to be used in the decision to use local acknowledgment for LLC2.
There are some situations (such as host B failing between the time host A sends data and the time host B receives it) in which host A would behave as if, at the LLC2 layer, data was received when it actually was not, because the device acknowledges that it received data from host A before it confirms that host B can actually receive the data. But because both NetBIOS and SNA have error recovery in situations where an end device goes down, these higher-level protocols will resend any missing or lost data. These transaction request/confirmation protocols exist above LLC2, so they are not affected by tight timers, as is LLC2. They also are transparent to local acknowledgment.
If you are using NetBIOS applications, note that there are two NetBIOS timers---one at the link level and one at the next higher level. Local acknowledgment for LLC2 is designed to solve session timeouts at the link level only. If you are experiencing NetBIOS session timeouts, you have two options:
In a configuration scenario where RSRB is configured between Router A and Router B and both routers are not routing IP, a Host connected to router A through Token Ring (or other LAN media) has no IP connectivity to router B. This restriction exists because IP datagrams received from the Host by Router A are encapsulated and sent to router B where they can only be de-encapsulated and source-bridged to a Token Ring. In this scenario, IP routing is recommended. To enable the Host to reach Router B in this scenario, IP routing should be enabled on Router A's Token Ring interface to which the Host is attached.
Data-Link Switching Plus (DLSw+) is a method of transporting SNA and NetBIOS. It complies with the DLSw standard documented in RFC 1795 as well as the DLSw Version 2 standard. DLSw+ is an alternative to RSRB that addresses several inherent problems that exist in RSRB, such as:
This section contains a brief overview of DLSw+ which is described in the following topics:
The DLSw standard does not specify when to establish TCP connections. The capabilities exchange allows compliance to the standard, but at different levels of support. The standard does not specify how to cache learned information about MAC addresses, RIFs, or NetBIOS names. It also does not describe how to track either capable or preferred DLSw partners for either backup or load-balancing purposes.The standard does not provide the specifics of media conversion, but leaves the details up to the implementation. It does not define how to map switch congestion to the flow control for data-link control. Finally, the MIB is documented under a separate RFC.
In the Version 1 standard, a network design requires fully meshed connectivity so that all peers were connect to every other peer. This design creates unnecessary broadcast traffic because an explorer propagates to every peer for every broadcast.
The Version 2 standard is documented in RFC 2166. It includes RFC 1795 and adds the following enhancements:
Users implement DLSw+ Version 2 for scalability if they are using multivendor DLSw devices with an IP multicast network. DLSw Version 2 requires complex planning because it involves configuration changes across an IP network.
DLSw Version 2 is for customers who run a multicast IP network and do not need the advantages of border peering.
DLSw+ is Cisco's version of DLSw and it supports several additional features and enhancements. DLSw+ is a means of transporting SNA and NetBIOS traffic over a campus or WAN. The end systems can attach to the network over Token Ring, Ethernet, Synchronous Data Link Control (SDLC) Protocol, Qualified Logical Link Control (QLLC), or FDDI. See the DLSw+ Design and Implementation Guide Appendix B, "DLSw+ Support Matrix," for details. DLSw+ switches between diverse media and locally terminates the data links, keeping acknowledgments, keepalives, and polling off the WAN. Local termination of data links also eliminates data-link control timeouts that can occur during transient network congestion or when rerouting around failed links. Finally, DLSw+ provides a mechanism for dynamically searching a network for SNA or NetBIOS resources and includes caching algorithms that minimize broadcast traffic.
This section contains information on the following topics related to DLSw+ features:
DLSw+ is fully compatible with any vendor's RFC 1795 implementation and the following features are available when both peers are using DLSw+:
When you have LANs separated by wide geographic distances, and you want to avoid multiple retransmissions or loss of user sessions that can occur with time delays, encapsulate the source-route bridged traffic inside IP datagrams passed over a TCP connection between two routers with local acknowledgment enabled.
In a typical LLC2 session, when one host sends a frame to another host, the sending host expects the receiving host to respond positively or negatively in a predefined period of time commonly called the T1 time. If the sending host does not receive an acknowledgment of the frame it sent within the T1 time, it retries a few times (normally 8 to 10). If there is still no response, the sending host drops the session.
Figure 86 illustrates an LLC2 session in which a 37x5 on a LAN segment communicates with a 3x74 on a different LAN segment separated via a wide-area backbone network. Frames are transported between Router A and Router B by means of DLSw+. However, the LLC2 session between the 37x5 and the 3x74 is still end-to-end; that is, every frame generated by the 37x5 traverses the backbone network to the 3x74, and the 3x74, on receipt of the frame, acknowledges it.
On backbone networks consisting of slow serial links, the T1 timer on end hosts could expire before the frames reach the remote hosts, causing the end host to retransmit. Retransmission results in duplicate frames reaching the remote host at the same time as the first frame reaches the remote host. Such frame duplication breaks the LLC2 protocol, resulting in the loss of sessions between the two IBM machines.
One way to solve this time delay is to increase the timeout value on the end nodes to account for the maximum transit time between the two end machines. However, in networks consisting of hundreds or even thousands of nodes, every machine would need to be reconfigured with new values. With local acknowledgment for LLC2 enabled, the LLC2 session between the two end nodes would not be not end-to-end, but instead, would terminate at two local routers. Figure 87 shows the LLC2 session with the 37x5 ending at Router A and the LLC2 session with the 3x74 ending at Router B. Both Router A and Router B execute the full LLC2 protocol as part of local acknowledgment for LLC2.
Enabling local acknowledgment for LLC2 has the following advantages:
LLC2 local acknowledgment is enabled with TCP and DLSw+ Lite remote peers.
If the LLC2 session between the local host and the router terminates in either router, the other will be informed to terminate its connection to its local host.
If the TCP queue length of the connection between the two routers reaches the high-water mark, the routers sends Receiver-Not-Ready (RNR) messages to the local hosts until the queue limit is reduced to below this limit. It is possible, however, to prevent the RNR messages from being sent by using the dlsw llc2 nornr command.
The configuration of the LLC2 parameters for the local Token Ring interfaces can affect overall performance. Refer to the chapter "Configuring LLC2 and SDLC Parameters" in this manual for more details about fine-tuning your network through the LLC2 parameters.
The routers at each end of the LLC2 session execute the full LLC2 protocol, which could result in some overhead. The decision to use local acknowledgment for LLC2 should be based on the speed of the backbone network in relation to the Token Ring speed. For LAN segments separated by slow-speed serial links (for example, 56 kbps), the T1 timer problem could occur more frequently. In such cases, it might be wise to turn on local acknowledgment for LLC2. For LAN segments separated by a T1, backbone delays will be minimal; in such cases, FST or direct should be considered. Speed mismatch between the LAN segments and the backbone network is one criterion to help you decide to use local acknowledgment for LLC2.
There are some situations (such as the receiving host failing between the time the sending host sends data and the time the receiving host receives it), in which the sending host would determine, at the LLC2 layer, that data was received when it actually was not. This error occurs because the router acknowledges that it received data from the sending host before it determines that the receiving host can actually receive the data. But because both NetBIOS and SNA have error recovery in situations where an end device goes down, these higher-level protocols will resend any missing or lost data. Because these transaction request/confirmation protocols exist above LLC2, they are not affected by tight timers, as is LLC2. They also are transparent to local acknowledgment.
If you are using NetBIOS applications, note that there are two NetBIOS timers---one at the link level and one at the next higher level. Local acknowledgment for LLC2 is designed to solve link timeouts only. If you are experiencing NetBIOS session timeouts, you have two options:
DLSw+ can be used as a transport for SNA features such as LAN Network Manager (LNM), DSPU, SNA service point, and SNA Switching Services (SNASw) through a Cisco IOS feature called virtual data-link control (VDLC).
LNM over DLSw+ allows DLSw+ to be used in Token Ring networks that are managed by IBM's LNM software. Using this feature, LNM can be used to manage Token Ring LANs, control access units, and Token Ring attached devices over a DLSw+ network. All management functions continue to operate as they would in a source-route bridged network or an RSRB network.
DSPU over DLSw+ allows Cisco's DSPU feature to operate in conjunction with DLSw+ in the same router. DLSw+ can be used either upstream (toward the mainframe) or downstream (away from the mainframe) of DSPU. DSPU concentration consolidates the appearance of multiple physical units (PUs) into a single PU appearance to VTAM, minimizing memory and cycles in central site resources (VTAM, NCP, and routers) and speeding network startup.
SNA service point over DLSw+ allows Cisco's SNA service point feature to be used in conjunction with DLSw+ in the same router. Using this feature, SNA service point can be configured in remote routers, and DLSw+ can provide the path for the remote service point PU to communicate with NetView. This allows full management visibility of resources from a NetView 390 console, while concurrently offering the value-added features of DLSw+ in an SNA network.
SNASw over DLSw+ allows Cisco's APPN Branch Extender functionality to be used in conjunction with DLSw+ in the same router. With this feature, DLSw+ can be used to access SNASw in the data center. DLSw+ can also be used as a transport SNASw upstream connectivity, providing nondisruptive recovery from failures. The DLSw+ network can appear as a connection network to the SNASw nodes.
Using DLSw+ as a transport for other Cisco IOS SNA features requires a feature called VDLC. Cisco IOS data-link users (such as LNM, DSPU, SNA service point, and SNASw) write to a virtual data-link control interface. DLSw+ then reads from this interface and sends out the traffic. Similarly, DLSw+ can receive traffic destined for one of these Data Link Users and write it to the virtual data-link control interface, from which the appropriate Data Link User will read it.
In Figure 88, SNASw and DLSw+ use Token Ring and Ethernet, respectively, as "real" data-link controls, and use virtual data-link control to communicate between themselves. When one of the high-layer protocols passes data to the virtual data-link control, the virtual data-link control must pass it to a higher-layer protocol; nothing leaves the virtual data-link control without going through a data-link user.
The higher-layer protocols make no distinction between the VDLC and any other data-link control, but they do identify the VDLC as a destination. In the example shown in , SNASw has two ports: a physical port for Token Ring and a logical (virtual) port for the VDLC. In the case of the SNASw VDLC port, when you define the SNASw VDLC port, you can also specify the MAC address assigned to it. That means data going from DLSw+ to SNASw by way of the VDLC is directed to the VDLC MAC address. The type of higher-layer protocol you use determines how the VDLC MAC address is assigned.
The Cisco IOS software supports serial tunnel (STUN) and block serial tunnel (BSTUN). Our BSTUN implementation enhances Cisco 2500, 4000, 4500, 4700, 7200 series routers to support devices that use the Binary Synchronous Communication (Bisync) data-link protocol and asynchronous security protocols that include Adplex, ADT Security Systems, Inc., Diebold, and asynchronous generic traffic. BSTUN implementation is also supported on the 4T network interface module (NIM) on the Cisco series 4000 and 4500. Our support of the bisync protocol enables enterprises to transport Bisync traffic and SNA multiprotocol traffic over the same network.
This section contains the following topics:
STUN operates in two modes: passthrough and local acknowledgment. shows the difference between passthrough mode and local acknowledgment mode.
The upper half of Figure 89 shows STUN configured in passthrough mode. In passthrough mode, the routers act as a wire and the SDLC session remains between the end stations. In this mode, STUN provides a straight passthrough of all SDLC traffic, including control frames.
The lower half of Figure 89 shows STUN configured in local acknowledgment mode. In local acknowledgment mode, the routers terminate the SDLC sessions and send only data across the WAN. Control frames no longer travel the WAN backbone networks.
|
Note To enable STUN local acknowledgment, you first enable the routers for STUN and configure them to appear on the network as primary or secondary SDLC nodes. TCP/IP encapsulation must be enabled. Cisco's STUN local acknowledgment feature also provides priority queueing for TCP-encapsulated frames. |
Cisco's STUN implementation provides the following features:
The Bisync feature enables your Cisco 2500, 3600, 4000, 4500, 4700, and 7200 series router to support devices that use the Bisync data-link protocol. This protocol enables enterprises to transport Bisync traffic over the same network that supports their SNA and multiprotocol traffic, eliminating the need for separate Bisync facilities.
At the access router, traffic from the attached Bisync device is encapsulated in IP. The Bisync traffic can then be routed across arbitrary media to the host site where another router supporting Bisync will remove the IP encapsulation headers and present the Bisync traffic to the Bisync host or controller over a serial connection. HDLC can be used as an alternative encapsulation method for point-to-point links.
Cisco's implementation of BSTUN provides the following features:
|
Note The async-generic item, listed above, is not a protocol name. It is a command keyword used to indicate generic support of other asynchronous security protocols that are not explicitly supported. |
The LLC2 and SDLC protocols provide data link layer support for higher-layer network protocols and features such as SDLC Logical Link Control (SDLLC) and RSRB with local acknowledgment. The features that are affected by LLC2 parameter settings are listed in the next section, "Cisco's Implementation of LLC2." The features that require SDLC configuration and use SDLC parameters are listed in the section "Cisco's Implementation of SDLC" later in this chapter.
SDLC is used as the primary SNA link-layer protocol for WAN links. SDLC defines two types of network nodes: primary and secondary. Primary nodes poll secondary nodes in a predetermined order. Secondary nodes then transmit any outgoing data. When configured as primary and secondary nodes, our routers are established as SDLC stations.
Cisco's LLC2 implementation supports the following features:
Cisco's SDLC implementation supports the following features:
The Cisco IOS software includes the following media translation features that enable network communications across heterogeneous media:
SDLLC is a Cisco Systems proprietary software feature that enables a device on a Token Ring to communicate with a device on a serial link by translating between LLC2 and SDLC at the link layer.
SNA uses SDLC and LLC2 as link layer protocols to provide a reliable connection. The translation function between these industry-standard protocols takes place in the proprietary Cisco software.
This section contains a brief overview of IBM Network Media Translation which is described in the following topics:
Figure 91 illustrates how SDLLC provides data link layer support for SNA communication.
The SDLLC feature allows a PU 4, PU 2.1, or PU 2 to communicate with a PU 2 SDLC device as follows:
In all these topologies, each IBM end node (the FEP and cluster controller) has no indication that its counterpart is connected to a different medium running a different protocol. The 37x5 FEP responds as if the 3x74 cluster controller were communicating over a Token Ring, whereas the 3x74 responds as though the 37x5 FEP were communicating over a serial line. That is, the SDLLC software makes translation between the two media transparent to the end nodes.
Central to Cisco's SDLLC feature is the concept of a virtual Token Ring device residing on a virtual Token Ring. Because the Token Ring device expects the node with which it is communicating also to be on a Token Ring, each SDLLC device on a serial line must be assigned an SDLLC virtual Token Ring address (SDLLC VTRA). Like real Token Ring addresses, SDLLC VTRAs must be unique across the network.
In addition to the SDLLC VTRA, an SDLLC virtual ring number must be assigned to each SDLLC device on a serial line. (The SDLLC virtual ring number differs from the virtual ring group numbers that are used to configure RSRB and multiport bridging.)
As part of its virtual telecommunications access method (VTAM) configuration, the IBM node on the Token Ring has knowledge of the SDLLC VTRA of the serial device with which it communicates. The SDLC VTRA and the SDLLC virtual ring number are a part of the SDLLC configuration for the router's serial interface. When the Token Ring host sends out explorer packets with the SDLLC VTRA as the destination address in the MAC headers, the router configured with that SDLLC VTRA intercepts the frame, fills in the SDLLC virtual ring number address and the bridge number in the RIF, then sends the response back to the Token Ring host. A route is then established between the Token Ring host and the router. After the Cisco IOS software performs the appropriate frame conversion, the system uses this route to forward frames to the serial device.
IBM nodes on Token Ring media normally use frame sizes greater than 1 KB, whereas the IBM nodes on serial lines normally limit frame sizes to 265 or 521 bytes. To reduce traffic on backbone networks and provide better performance, Token Ring nodes should send frames that are as large as possible. As part of the SDLLC configuration on the serial interface, the largest frame size the two media can support should be selected. The Cisco IOS software can fragment the frames it receives from the Token Ring device before forwarding them to the SDLC device, but it does not assemble the frames it receives from the serial device before forwarding them to the Token Ring device.
SDLLC maintains a dynamic RIF cache and caches the entire RIF; that is, the RIF from the source station to destination station. The cached entry is based on the best path at the time the session begins. SDLLC uses the RIF cache to maintain the LLC2 session between the router and the host FEP. SDLLC does not age these RIF entries. Instead, SDLLC places an entry in the RIF cache for a session when the session begins and flushes the cache when the session terminates. You cannot flush these RIFs because if you flush the RIF entries randomly, the Cisco IOS software cannot maintain the LLC2 session to the host FEP.
The following are additional facts regarding SDLC and SDLLC:
Qualified Logical Link Control (QLLC) is a data link protocol defined by IBM that allows SNA data to be transported across X.25 networks. (Although IBM has defined other protocols for transporting SNA traffic over an X.25 network, QLLC is the most widely used.) Figure 92 illustrates how QLLC conversion provides data link layer support for SNA communication.
As shown in Figure 93, any devices in the SNA communication path that use X.25, whether end systems or intermediate systems, require a QLLC implementation.
As shown in Figure 94, the QLLC conversion feature eliminates the need to install the X.25 software on local IBM equipment. A device attached locally to a Token Ring network can communicate through a router running the QLLC Conversion feature with a remote device attached to an X.25 network using QLLC. Typically, the locally attached device is an FEP, an AS 400, or a PS/2, and the remote device is a terminal controller or a PS/2. In this case, only the remote device needs an X.25 interface and the FEP can communicate with the terminal controller as if it were directly attached via a Token Ring network.
More elaborate configurations are possible. The router that implements QLLC conversion need not be on the same Token Ring network as the FEP. As shown in Figure 95, QLLC/LLC2 conversion is possible even when an intermediate IP WAN exists between the router connected to the X.25 network and the router connected to the Token Ring.
SNA uses QLLC and X.25 as link layer protocols to provide a reliable connection. QLLC itself processes QLLC control packets. In a Token Ring environment, SNA uses LLC to provide a reliable connection. The LAN-to-X.25 (LNX) software provides a QLLC conversion function to translate between LLC and QLLC.
Figure 96 shows the simplest QLLC conversion topology: a single Token Ring device (for example, a 37x5 FEP) communicates with a single remote X.25 device (in this case a 3x74 cluster controller). In this example, a router connects the Token Ring network to the X.25 network.
In Figure 96, each IBM end node has no indication that its counterpart is connected to a different medium running a different protocol. The 37x5 FEP responds as if the 3x74 cluster controller were communicating over a Token Ring, whereas the 3x74 responds as though the 37x5 FEP were communicating over an X.25 network. This is accomplished by configuring the router's X.25 interface as a virtual Token Ring, so that the X.25 virtual circuit appears to the Token Ring device (and to the router itself) as if it were a Token Ring to which the remote X.25 device is attached.
Also in this figure, the LLC2 connection extends from the 37x5 FEP across the Token Ring network to the router. The QLLC/X.25 session extends from the router across the X.25 network to the 3x74 cluster controller. Only the SNA session extends across the Token Ring and X.25 networks to provide an end-to-end connection from the 37x5 FEP to the 3x74 cluster controller.
As Figure 97 shows, a router need not directly connect the two IBM end nodes; instead, some type of backbone WAN can connect them. Here, RSRB transports packets between Router A and Router B, while Router B performs all conversion between the LLC2 and X.25 protocols. Only the router attached to the serial line (Router B) needs to be configured for QLLC conversion. Both Router A and Router B are configured for normal RSRB.
How communication sessions are established over the communication link varies depending on whether or not LLC2 local acknowledgment has been configured on Router A's Token Ring interface. In both cases, the SNA session extends end-to-end and the QLLC/X.25 session extends from Router B to the 3x74 cluster controller. If LLC2 local acknowledgment has not been configured, the LLC2 session extends from the 37x5 FEP across the Token Ring network and the arbitrary WAN to Router B. In contrast, when LLC2 local acknowledgment has been configured, the LLC2 session extends from the 37x5 FEP Router A, where it is locally terminated. A TCP session is then used across the arbitrary WAN to Router B.
Although the procedures you use to configure QLLC are similar to those used to configure SDLLC, there are structural and philosophical differences between the point-to-point links that SDLC uses and the multiplexed virtual circuits that X.25 uses.
The most significant structural difference between QLLC conversion and SDLLC is the addressing. To allow a device to use LLC2 to transfer data, both SDLLC and QLLC provide virtual MAC addresses. In SDLLC, the actual MAC address is built by combining the defined virtual MAC (whose last byte is 0x00) with the secondary address used on the SDLC link; in this way, SDLLC supports multidrop. In QLLC conversion, multidrop is meaningless, so the virtual MAC address represents just one session and is defined as part of the X.25 configuration. Because one physical X.25 interface can support many simultaneous connections for many different remote devices, you only need one physical link to the X.25 network. The different connections on different virtual circuits all use the same physical link.
The most significant difference between QLLC conversion and SDLLC is the fact that a typical SDLC/SDLLC operation uses a leased line. In SDLC, dial-up connections are possible, but the maximum data rate is limited. In QLLC, both switched virtual circuits (SVCs) and permanent virtual circuits (PVCs) are available, but the favored use is SVC. While the router maintains a permanent connection to the X.25 network, a remote device can use each SVC for some bounded period of time and then relinquish it for use by another device. Using a PVC is very much like using a leased line.
Table 3 shows how the QLLC commands correspond to the SDLLC commands.
| QLLC Command | Analogous SDLLC Command |
|---|---|
qllc largest-packet | sdllc ring-largest-frame, sdllc sdlc-largest-frame |
qllc partner | sdllc partner |
qllc sap | sdllc sap |
qllc srb, x25 map qllc, x25 pvc qllc | sdllc traddr |
qllc xid | sdllc xid |
source-bridge qllc-local-ack | source-bridge sdllc-local-ack |
Consider the following when implementing QLLC conversion:
You can configure DLSw+ for QLLC connectivity, which enables the following scenarios:
For information on configuring DLSw+ for QLLC conversion, refer to the "Configuring DLSw+" chapter.
You can configure DSPUs for QLLC. For more information on this configuration, refer to the "Configuring DSPU and SNA Service Point" chapter.
Management service point support in FRAS allows the SNA network management application, NetView, to manage Cisco routers over the Frame Relay network as if it were an SNA downstream PU.
FRAS provides dial backup over RSRB in case the Frame Relay network is down. While the backup Public Switched Telephone Network (PSTN) is being used, the Frame Relay connection is tried periodically. As soon as the Frame Relay network is up, it will be used.
This section contains a brief overview of SNA FRAS which is described in the following topics:
The Frame Relay encapsulation method is based on the RFC 1490 frame format for "user-defined" protocols using Q.933 NLPID, as illustrated in Figure 98.
|
Note The protocol ID for SNA subarea FID4 is 0x81. The protocol ID for SNA subarea FID2 is 0x82. The protocol ID for APPN FID2 is 0x83. |
FRAS allows the router acting as a FRAD to take advantage of the SNA BNN support for Frame Relay provided by ACF/NCP 7.1 and OS/400 V2R3. Downstream PU 2.0 and PU 2.1 devices can be attached to the router through SDLC, Token Ring, or Ethernet links. The router acting as a FRAD is connected to the Network Control Program (NCP) or AS/400 through a public or private Frame Relay network, as illustrated in Figure 99.
The frame format that communicates across the Frame Relay BNN link is defined in RFC 1490 for routed SNA traffic. From the perspective of the SNA host (for example an NCP or AS/400), the Frame Relay connection is defined as a switched resource similar to a Token Ring BNN link. Because the frame format does not include link addresses to allow the NCP to distinguish among SNA devices on the same permanent virtual circuit, Cisco supports SAP multiplexing, which allows you to configure unique LLC2 SAPs for each downstream SNA device so that they can share a single permanent virtual circuit to an FEP.
The Cisco IOS software is responsible for terminating the local data-link control frames (such as SDLC and Token Ring frames) and for modifying the data-link control frames to 802.2 compliant LLC frames. The LLC provides a reliable connection-oriented link layer transport required by SNA. (For example, 802.2 LLC is used to provide link layer acknowledgment, sequencing, and flow control.)
The Cisco IOS software encapsulates these 802.2 LLC frames according to the RFC 1490 format for SNA traffic. The frames are then forwarded to the SNA host on a Frame Relay PVC. In the reverse direction, the software is responsible for de-encapsulating the data from the Frame Relay PVC, and for generating and transmitting the appropriate local data link control frames to the downstream devices.
BAN provides functionality similar to BNN except that it uses a bridged frame format, as illustrated in Figure 100.
Because it includes the MAC header information in every frame, BAN supports multiple SNA devices sharing a single permanent virtual circuit without requiring SAP multiplexing. BAN also supports load balancing across duplicate data-link connection identifiers to the same or different front-end processors at the data center to enhance overall availability. BAN works for devices attached by either Token Ring or Ethernet.
Native Client Interface Architecture (NCIA) is a new software architecture introduced by Cisco to make accessing IBM SNA applications over routed internetworks more scalable and flexible. NCIA is a component of the Cisco IOS software. The architecture is intended to combine the benefits of the native SNA interface at end stations and mainframes with those of TCP/IP across the network backbone.
NCIA extends the use of the TCP/IP protocol all the way to the SNA end station. Because of the wide range of media supported by TCP/IP, including dialup telephone lines for remotely located users, NCIA makes multiprotocol access to corporate backbone networks much more flexible for SNA users.
NCIA allows SNA end stations such as PCs or workstations to encapsulate SNA traffic in TCP/IP, rather than requiring the traffic to travel through routers. The first phase of NCIA (NCIA I), used Cisco RSRB encapsulation. The current phase (NCIA Server) uses a new client/server model. NCIA Server is not backward compatible to NCIA I.
This section contains a brief overview of NCIA which is described in the following topics:
Cisco's NCIA server feature implements RFC 2114, Data Link Switch Client Access Protocol. Using Cisco's RSRB technology, NCIA I encapsulates the Token Ring traffic inside IP datagrams passed over a TCP connection between a router and a client. A virtual ring is created to allow the router to interconnect any client. The virtual ring acts as a logical Token Ring in the router, so that all the Token Rings connected to the router are treated as if they are all on the same Token Ring. The virtual ring is called a ring group. The ring group number is used just like a physical ring number and shows up in any route descriptors contained in packets being bridged. A ring group must be assigned a ring number that is unique throughout the network.
An NCIA I client acts as both an RSRB router and an end station. It must have a "fake" ring number and a "fake" bridge number so that it looks like an end station sitting on a real Token Ring. The fake ring and bridge numbers are visible to both the RSRB router and the NCIA client. The client must also have an LLC2 so that it can handle the LLC2 sessions.
The NCIA Server feature extends the scalability of NCIA I, enhances its functionality, and provides support for both the installed base of RSRB routers and the growing number of DLSw+ routers. The NCIA Server feature includes the following enhancements:
The NCIA Server feature uses a client/server model (see Figure 101), where the NCIA server is a software module on a Cisco router and the NCIA client is a PC or workstation. The NCIA server performs two major functions:
NCIA Data Link Control (NDLC) is the protocol used between clients and servers. NDLC serves two purposes:
The peer session must be established before an end-to-end circuit can be set up. During the set up period for the peer session, the MAC address representing a client is defined. The MAC address can be defined by the client or by the server when the client does not have a MAC address.
The NCIA Server feature supports connect-in and connect-out (from the server's perspective), but connect-out is not supported if the client station does not listen for the incoming connection. For a server to connect-out, clients must connect to the server first. After registering itself by providing its own MAC address, the client can then optionally disconnect from the server. When a server receives an explorer, and its destination MAC address is registered, an NCIA server will connect to that client if it is not connected. For NetBIOS explorers (addressed to functional address 0xC00000000080), the TCP session must remain up so that the server can broadcast the explorers to the client. If the TCP session is down, the server will not send the NetBIOS explorers to a client, even when the client is registered.
After the peer session has been established, the NDLC protocol establishes the circuit between the client and server. This circuit is used to transfer end-user data between the client and the server. Because the client and its target station are not on the same transport, they cannot form a direct, end-to-end circuit. Each client must form a circuit between the client and server, and the server must form another circuit between the server and the target station. The server links those two circuits to form an end-to-end circuit. The server acts as a mediator between the client and the target station so that packets can be transferred between them.
In the NCIA server only peer keepalive is maintained. There is no keepalive at circuit level.
The NCIA server acts as a data-link provider, like Token Ring or Ethernet, in the router. It uses CLSI to communicate with other software modules, just as other data-link providers do. The network administrator configures the router to communicate with specific modules. For data-link users, such as SNASw, DLSw+, and DSPU, the NCIA server can interface to them directly. For other data-link providers, the NCIA server must go through a DLSw+ local peer to communicate with them. The DLSw+ local peer passes packets back and forth among different data-link providers.
The client/server model used in the NCIA Server feature extends the scalability of NCIA. In addition, it provides support for both the installed base of RSRB routers and the growing number of DLSw+ routers.
The client/server model minimizes the number of central site RSRB or DLSw+ peer connections required to support a large network of NCIA clients (see Figure 102). Rather than each client having a peer connection to a central site router, the clients attach to an IP backbone through an NCIA server that, in turn, has a single peer connection to a central site router. This scheme can greatly reduce the number of central site peer connections required. For example, in a network with 1000 clients and 10 NCIA servers, there would be only 10 central site peer connections. Note that there would still be 1000 LLC2 connections that must be locally acknowledged at the central site router, but this can easily be handled in a single central site router. When the number of LLC2 connections (or the number of clients) is in the tens of thousands, NCIA servers can take advantage of downstream PU concentration to minimize the number of LLC2 connections that must be supported by the central site routers.
Using a client/server model allows the NCIA Server feature to be independent of the upstream implementation, allowing it to be implemented in a network that is still using RSRB, as well as in a DLSw+ network. It also greatly simplifies migration from RSRB to DLSw+, because it requires no changes at the client. A single NCIA server can support either approach (but not both). As Figure 103 illustrates, a central site router can support RSRB and DLSw+ concurrently, allowing a portion of the NCIA servers to communicate using RSRB and another portion to communicate using DLSw+.
The Airline Product Set (ALPS) is a tunneling mechanism that transports airline protocol data across a TCP/IP network to a mainframe. ALPS provides connectivity between agent set control units (ASCUs) and a mainframe host that runs the airline reservation system.
Figure 104 shows the basic ALPS topology and the protocols implemented in the feature. Three major components provide the end-to-end transportation of airline protocol traffic across the network: the P1024B Airline Control (ALC) or P1024C (UTS) protocol, the TCP/IP-based MATIP protocol conversion, and the TCP/IP access to the mainframe.
Cisco's ALPS feature provides an end-to-end solution for airlines and central reservation systems.The ALPS feature is integrated in the Cisco IOS software and allows airlines to replace their existing hardware and software with Cisco routers. For customers who already use Cisco routers, this feature allows them to consolidate networking overhead and functionality.
Downstream physical unit (DSPU) is a software feature that enables the router to function as a PU concentrator for SNA PU type 2 nodes. PU concentration at the device simplifies the task of PU definition at the upstream host while providing additional flexibility and mobility for downstream PU devices.
The DSPU feature allows you to define downstream PU type 2 devices in the Cisco IOS software. DSPU reduces the complexity of host configuration by letting you replace multiple PU definitions that represent each downstream device with one PU definition that represents the router.
Because you define the downstream PUs at the router rather than the host, you isolate the host from changes in the downstream network topology. Therefore you can insert and remove downstream PUs from the network without making any changes on the host.
The concentration of downstream PUs at the router also reduces network traffic on the WAN by limiting the number of sessions that must be established and maintained with the host. The termination of downstream sessions at the router ensures that idle session traffic does not appear on the WAN.
SNA service point support in the Cisco IOS software assumes that NetView or an equivalent product is available at the SNA host. The user interacts with the network management feature in the router and at the SNA host. In the Cisco IOS software, you can configure the host connection and show the status of this connection. At the SNA host, you can use the NetView operator's console to view alerts and to send and receive Cisco syntax commands to the Cisco device.
Figure 105 shows a router functioning as a DSPU concentrator.
Typically, a router establishes one or more upstream connections with one or more hosts and many downstream connections with PU type 2 devices. From an SNA perspective, the router appears as a PU type 2 device to the upstream host and assumes the role of a system services control point (SSCP) appearing as a PU type 5 device to its downstream PUs.
The SSCP sessions established between the router and its upstream host are completely independent of the SSCP sessions established between the router and its downstream PUs. SNA traffic is routed at a logical unit (LU) level using a routing algorithm that maps downstream LUs onto upstream LUs.
Figure 106 illustrates the SNA perspective of DSPU.
|
Note SNA Switching Services functionality supersedes all functionality previously available in the APPN feature in the Cisco IOS software. SNASw configuration will not accept the previous APPN configuration commands. Previous APPN users should use this chapter to configure APPN functionality using the new SNASw commands. |
SNASw provides an easier way to design and implement networks with SNA routing requirements. Previously, this network design was accomplished using APPN with full network node (NN) support in the Cisco router. This type of support provided the SNA routing functionality needed, but was inconsistent with the trends in Enterprise networks today. The corporate intranet is replacing the SNA WAN. Enterprises are replacing their traditional SNA network with an IP infrastructure that supports traffic from a variety of clients, using a variety of protocols, requiring access to applications on a variety of platforms, including SNA applications on Enterprise servers.
While SNA routing is still required when multiple servers must be accessed, the number of nodes required to perform this function is decreasing as the IP infrastructure grows and as the amount of native SNA traffic in the network decreases.
SNASw enables an enterprise to develop their IP infrastructure, while meeting SNA routing requirements.
SNASw provides the following benefits:
Limiting SNASw routers to the data center and using the BEX function eliminates SNA broadcasts from the IP network. With Enterprise Extender (EE), SNA traffic is routed using the IP routing infrastructure while maintaining end-to-end SNA services.
By eliminating NNs and using the BEX function, configuration tasks are minimized. Additionally, Cisco has enhanced its auto-configuration capability to eliminate previously required commands.
By placing all SNA routers in the data center, few SNA routers are required, and they can be easily configured using virtually identical configurations.
By adding Cisco-unique capabilities to connect-out and distribute traffic across multiple ports, access to resources is improved and traffic can be distributed across multiple ports. Additionally, by supporting the newest HPR ARB flow control algorithm, bandwidth management for SNA traffic is improved.
Two new traces, interprocess and data-link, provide an easier way to view SNASw activity. The APPN Trap MIB allows the user to notify the operator in event of a debilitating problem. Console message archiving provides better tracking of network activity. The ability to format traces in a format so that they are readable by other management products simplify network management because results are more readily available.
Even though SNASw is easier to use and SNASw networks are easier to design, SNASw interfaces with SNA implementations on the market: upstream NNs, end nodes (ENs), low-entry networking (LEN) nodes and PU 2.0. It also provides full DLUR support to allow dependent PU and LU traffic to flow over the APPN network to SNA data hosts.
SNASw provides the following SNA routing functions:
SNA Switching Services enables BE functionality by default. SNASw treats all defined links as BE "uplinks" and all dynamic links created by stations connecting into SNASw as BE "downlinks." No specific configuration is necessary to enable BE functionality.
Figure 107 illustrates the BX functionality.
SNASw also supports the EE function. EE offers SNA HPR support directly over IP networks. EE also uses connectionless User Datagram Protocol (UDP) transport. SNA COS and transmission priority are maintained by mapping the transmission priority to the IP precedence and by mapping transmission priority to separate UDP port numbers, allowing the IP network to be configured based on these elements. Cisco's IP prioritization technologies, such as weighted fair queueing (WFQ), prioritize the traffic through the IP network. EE support on the IBM Communications Server for S/390 allows users to build highly reliable SNA routed networks that run natively over an IP infrastructure directly to the Enterprise servers. These network designs reduce points of failure in the network and provide reliable SNA networks.
Figure 108 illustrates the EX functionality.
SNASw contains the following usability features designed to make SNA networks easier to design and maintain:
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 hostname 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. Administrators can still explicitly configure the CP name within the SNASw configuration.
Most SNA node implementations require specific tuning of the SNA basic transmit unit (BTU) in the configuration. SNASw analyzes the interface maximum transfer units (MTUs) of the 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 dynamically sets the SNA BTU for that device to the MAXDATA value.
SNASw can receive connect-out instructions from the IBM Communications Server for S/390. 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. |
Early HPR implementations failed to perform well in environments subject to packet loss (for example, Frame Relay, IP transport) and performed poorly when combined with other protocols in multiprotocol networks. SNASw implements the second-generation HPR flow control architecture, called Responsive Mode Adaptive Rate-Based (ARB) architecture. Responsive Mode ARB addresses all the drawbacks of the earlier ARB implementation, providing faster ramp-up, better tolerance of lost frames, and better tolerance of multiprotocol traffic.
SNASw offers full control over the number of devices supported by a specific port. The max-links configuration on the SNASw port controls the number of devices that are served by this port. When the max-links limit is reached, SNASw no longer responds to test frames attempting to establish new connections. SNASw allows load sharing among different SNASw nodes that offer service to the same SNA MAC addresses.
SNASw contains the following enhanced tools for managing SNA networks:
Messages issued by SNASw are archived in a buffer 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 buffer log also maintains more detailed information about the message issued.
SNA frames entering or leaving SNASw are traced to the console or to a cyclic buffer. These frames are analyzed at the router or transferred to a file server for analysis. The trace is sent to a file server in a SNA-formatted text file or in binary format readable by existing traffic analysis applications.
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.
SNASw supports the APPN Trap MIB, which proactively sends traps with information about changes in SNA resource status. This implementation reduces the frequency of SNMP polling necessary to manage SNA devices in the network.
SNASw supports several connection types to serve all SNA connectivity options, including the following types:
SNASw natively supports connectivity to Token Ring, Ethernet, and FDDI networks. In this configuration mode, the MAC address used by SNASw is the local configured or default MAC address of the interface.
Using virtual Token Ring allows SNASw access to SRB, which allows the following configuration:
Virtual Token Ring allows you to connect to local LAN media through SRB technology. Because there is no limit to the number of virtual Token Ring interfaces that can connect to a specific LAN, this technology allows configuration of multiple MAC addresses, which respond to SNA requests over the same LAN. When using native LAN support, SNASw responds only to requests that target the MAC address configured on the local interface. Virtual Token Ring and SRB allow SNASw to respond to multiple MAC addresses over the same physical interface.
Virtual Token Ring and SRB connect SNASw to a SNA Frame Relay infrastructure. FRAS host and SRB Frame Relay are configured to connect virtual Token Ring interfaces that offer SNASw support for Frame Relay boundary access node (BAN) or boundary network node (BNN) technology.
Virtual Token Ring and SRB can be used to connect SNASw to the Channel Interface Processor (CIP) or Channel Port Adapter (CPA) in routers that support those interfaces.
SNASw uses Virtual Data-Link Control (VDLC) to connect to DLSw+ transport and local switching technologies. VDLC is used for a number of connectivity options, including the following two:
Using VDLC, SNASw gains full access to the DLSw+ transport facilities, including DLSw+ transport over IP networks, DLSw+ transport over direct interfaces, and DLSw+ support of direct Frame Relay encapsulation (without using IP).
Through VDLC, SNASw gains access to devices connecting through SDLC and QLLC. This access allows devices connecting through SDLC and QLLC access to SNASw.
This section contains the following topics:
The CTRC software feature provides the following functionality:
CTRC is a Cisco IOS software feature that is available in two environments:
When a router is configured to use CTRC for communications with CICS systems, the router converts ISC packets over TCP/IP to ISC packets over Advanced Program-to-Program Communications (APPC) LU 6.2 and then routes them to the appropriate CICS region. CTRC converts CICS client messages received via TCP/IP to SNA messages and uses Cisco SNA Switching Services to transmit them to the host.
CTRC runs as a TCP/IP daemon on the router, accepting ISC client connections over TCP/IP. When a client connects to a CICS region on an IBM mainframe host, CTRC allocates an APPC conversation over SNA to an IBM server and acts as a gateway between ISC over TCP/IP and ISC over APPC.
Figure 109 illustrates how CTRC lets CICS client applications on TCP/IP networks interact with CICS transaction monitoring systems on IBM hosts.
CTRC enables Cisco routers to implement IBM's DRDA over TCP/IP. The Cisco router with CTRC exists in the TCP/IP network, and clients use a CTRC IP address and port on the router to connect to the IBM host system that exists in either an SNA network or a TCP/IP network.
When CTRC is appropriately configured on a router, client-based ODBC applications can connect to the following IBM D2 relational databases:
For an SNA host connection, the router with CTRC converts DRDA packets over TCP/IP to DRDA packets over (APPC LU 6.2) and then routes them to DB2 databases. CTRC runs as a TCP/IP daemon on the router, accepting DRDA client connections over TCP/IP. When a client connects to the database on an IBM mainframe host, CTRC allocates an APPC conversation over SNA to an IBM server, and acts as a gateway between DRDA over TCP/IP and DRDA over APPC.
Figure 110 illustrates how the Cisco router configured with the CTRC feature enables the exchange of database information between ODBC client applications running DRDA in a TCP/IP network and a DRDA-based IBM system that accesses DB2 relational data.
For a TCP/IP host connection, the router with CTRC routes the DRDA packets over TCP/IP without protocol changes. To use this TCP/IP passthrough feature of CTRC, the host database version must support direct TCP/IP access. Figure 111 illustrates such a configuration.
When configured for DB2 communications on a router, the CTRC feature enables desktop applications to access data in remote databases located on IBM hosts. CTRC receives database access messages from the client over a TCP/IP link. CTRC either converts the messages to SNA and transmits them to the host using APPC services provided by the Cisco SNA Switching Services, or routes the client messages to the TCP/IP-enabled host without protocol changes.
CTRC provides TCP/IP end-users and servers with fast, reliable, and secure access to IBM DB2 databases using the SNA protocol. CTRC replaces expensive and hard to manage UNIX and NT gateways for database access.
CTRC lets Windows or UNIX client applications call CICS transactions without requiring changes to the client or host software.
In addition, CTRC provides Cisco 7200 and 7500 series routers with the functionality previously available in CDBC, which gives ODBC client applications access to data in DB2 databases.
Each type of adapter (CIP or CPA) supports both ESCON and parallel channel attachment to the host and can eliminate the need for a separate FEP.
Figure 112 shows the type of channel connections and environments supported by the CMCC adapters.
The Cisco 7000 with RSP7000 and Cisco 7500 series routers support online insertion and removal (OIR), which allows you to install or remove CIPs while the system is operating.
The only differences between CMCC software applications running on the CIP and a CPA are performance and capacity. The performance difference is based upon differences in the internal bus architecture of a CIP and a CPA, and the capacity difference is based on the difference in maximum memory configurations (128 MB for CIP and 32 MB for CPA). For more information about differences between the CIP and CPA, see the "Differences between the CIP and CPA" section.
The Cisco 7200 series router supports online insertion and removal (OIR), which allows you to install or remove port adapters while the system is operating.
|
Note In this chapter, references to Channel Port Adapter (CPA) correspond to both the ECPA and the PCPA. Refer to the Cisco 7200 Series Port Adapter Hardware Configuration Guidelines publication for more details. |
Table 4 illustrates the differences between the CMCC adapters.
| Product Differences | CIP | ECPA | PCPA |
|---|---|---|---|
Cisco 7500 | Cisco 7200 | Cisco 7200 | |
ESCON | ESCON | Parallel | |
2 | 1 | 1 | |
128 MB | 32 MB | 32 MB | |
Cisco IOS Release 10.2 and later | Cisco IOS Release 11.3(3)T and later | Cisco IOS Release 11.3(3)T and later | |
2 | 0 | 0 | |
Yes | Disabled---Use the state-tracks-signal command to enable | Disabled---Use the state-tracks-signal command to enable |
The Cisco IOS software supports the following environments and features on the CMCC adapters:
The Cisco IOS software supports the following features for CMCC adapters in TCP/IP environments:
The CLAW packing feature enables the transport of multiple IP packets in a single channel operation and significantly increases throughput performance between a mainframe and a CMCC adapter. Currently, IBM's TCP/IP stack does not support the CLAW packing feature.
The CLAW packing feature requires changes to the mainframe CLAW driver support. In partnership with Cisco, Interlink Computer Science (now Sterling Software) has made the corresponding CLAW driver change to Cisco IOS for S/390 Release 2 and Interlink TCPaccess 5.2. Customers must make the necessary changes to their host configurations in order to enable the CLAW packing feature.
For details about configuring a CMCC adapter for CLAW, see the "Configuring CLAW and TCP/IP Offload Support" chapter in this publication.
For details about configuring a CMCC adapter for TCP/IP offload, see the "Configuring CLAW and TCP/IP Offload Support" chapter in this publication.
You can connect multiple mainframes to a single CMCC adapter using an ESCON director. Often, these mainframes run using the ESCON Multiple Image Facility (EMIF), which permits the physical machine to be divided into multiple logical partitions (LPARs). By defining an unused partition on another mainframe, a user can move the operating system from a failed mainframe or mainframe partition to the unused partition. By having multiple paths to each device, the move is accomplished without changing the mainframe software. This function also permits moving an IP stack between multiple operating system images.
On the CMCC adapter, each IP connection is treated as a physical device. The CMCC adapter does not support multiple active paths to a single IP connection (or device). Prior to IP Host Backup, the router configuration had to be changed whenever the mainframe operating system was moved from one mainframe or LPAR to another. The IP Host Backup feature permits the mainframe operating system to be moved from one mainframe to another without requiring a change to the router configuration at the time of the move.
|
Note IP Host Backup does not provide single system image or automatic failover to a waiting backup application. Host operator action on the mainframe is required in these instances. |
For more information about configuring a CMCC adapter for IP host backup, see the "Configuring CLAW and TCP/IP Offload Support" chapter in this publication.
CMPC+ is Cisco's implementation of IBM's MPC+ feature. The CMPC+ feature supports the MPC+ features and protocols necessary to support IP. CMPC+ enables High Performance Data Transfer (HPDT). It allows TCP/IP connections to the host through CMCC adapters, using either the TCP/IP stack or the High Speed Access Services (HSAS) IP stack.
CMPC+ offers the following support:
Up to 64 MPC+ groups can be configured on a CMCC, depending on memory configuration.
The CMPC+ feature can coexist with the CLAW, TCP/IP Offload, CSNA, CMPC, and TN3270 server features on the same CMCC adapter.
For details about configuring a CMCC adapter for CMPC+, see the "Configuring CMPC+" chapter in this publication.
The Cisco IOS software supports the following features for CMCC adapters in SNA environments:
The CSNA feature provides support for SNA protocols to the IBM mainframe from Cisco 7500,
Cisco 7200, and Cisco 7000 with RSP7000 series routers, using CMCC adapters (over both ESCON and parallel interfaces). As an IBM 3172 replacement, a CMCC adapter in a Cisco router supports the External Communications Adapter (XCA) feature of the Virtual Telecommunications Access Method (VTAM).
Support for the XCA feature allows VTAM to define the CMCC's Token Ring devices as switched devices. XCA support also allows the CMCC adapter to provide an alternative to FEPs at sites where the NCP is not required for SNA routing functions.
CSNA also supports communication between two mainframes running VTAM that are either channel-attached to the same CMCC adapter card, or channel-attached to different CMCC adapter cards.
The CSNA feature provides SNA connectivity through a MAC address that is defined on an internal adapter in a CMCC. The internal adapter is a virtual adapter that emulates the LAN adapter in an IBM 3172 Interconnect Controller. Each internal adapter is defined in a corresponding XCA major node in VTAM, which provides an access point (LAN gateway) to VTAM for SNA network nodes.
The internal adapter is configured on an internal (virtual) Token Ring LAN located in the CMCC. Each CMCC can be configured with multiple internal Token Ring LANs and internal adapters. Each internal Token Ring LAN must be configured to participate in source-route bridging to communicate with the LAN devices attached to the router.
By providing Cisco Link Services (CLS) and the LLC2 protocol stack on the CMCC adapter card, all frames destined to or from the CMCC adapter card are switched by the router. The presentation of LAN media types allows the CSNA feature to take advantage of current SRB, RSRB, DLSw+, SR/TLB, internal SDLLC, QLLC services, and APPN functionality through SNASw.
The CSNA feature can coexist with the CLAW, TCP/IP Offload, CMPC, CMPC+, and TN3270 server features on the same CMCC adapter.
For details about configuring a CMCC adapter for CSNA, see the "Configuring CSNA and CMPC" chapter in this publication.
CMPC is Cisco System's implementation of IBM's MultiPath Channel (MPC) feature on Cisco 7500, Cisco 7200, and Cisco 7000 with RSP7000 series routers. CMPC allows VTAM to establish Advanced-Peer-to-Peer Networking (APPN) connections using both High Performance Routing (HPR) and Intermediate Session Routing (ISR) through channel-attached router platforms.
Routers configured for CMPC can be deployed in Parallel MVS Systems Complex (sysplex) configurations.
CMPC can be used to establish an APPN connection between VTAM and the following types of APPN nodes:
One read subchannel and one write subchannel are supported for each MPC transmission group. The read subchannel and write subchannel may be split over two physical channel connections on the same CMCC adapter.
CMPC insulates VTAM from the actual network topology. The MPC protocols are terminated on the CMCC adapter and converted to LLC protocols. After they are converted to LLC protocols, other Cisco features can be used to connect VTAM to other APPN nodes in the network. CMPC can be used in conjunction with DLSw+, RSRB, SR/TLB, SRB, SDLLC, QLLC, ATM LAN emulation, and FRAS host to provide connectivity to VTAM.
The CMPC feature can coexist with the CLAW, TCP/IP Offload, CSNA, CMPC+, and TN3270 server features on the same CMCC adapter.
For details about configuring a CMCC adapter for CMPC, see the "Configuring CSNA and CMPC" chapter of this guide.
TN3270 communications in a TCP/IP network consist of the following basic elements:
The TN3270 server feature offers an attractive solution when the following conditions need to be supported in an SNA environment:
The TN3270 server feature on a CMCC adapter card provides mapping between an SNA 3270 host and a TN3270 client connected to a TCP/IP network as shown in Figure 113. Functionally, it is useful to view the TN3270 server from two different perspectives:
The LUs implemented by the TN3270 server are dependent LUs. To route these dependent LU sessions to multiple VTAM hosts connected to the TN3270 server in the CMCC adapter card, rather than routing in the VTAM hosts, the TN3270 server implements a SNA session switch with EN DLUR function. SNA session switching allows you to eliminate SNA subarea routing between hosts of TN3270 traffic by establishing APPN links with the primary LU hosts directly.
Using the DLUR function is optional so that the TN3270 server can be used with VTAM versions prior to version 4.2, which provide no APPN support. In these non-APPN environments, access to multiple hosts is accomplished using direct PU configuration in the TN3270 server.
From the perspective of a TN3270 client, the TN3270 server is a high-performance Telnet server that supports Telnet connections, negotiation and data format. The server on the CMCC adapter card supports Telnet connection negotiation and data format as specified in RFC 1576 (referred to as "traditional TN3270") and RFC 2355 (referred to as "TN3270 Enhancements").
Unless the TN3270 server uses a Token Ring connection to a FEP, or other LLC connectivity to the mainframe host, it requires CSNA or CMPC support. For more information about configuring CSNA or CMPC support, see the "Configuring CSNA and CMPC" chapter in this publication.
|
Note To enable the TN3270 server feature, you must have a CMCC adapter installed in a Cisco 7000 with RSP7000, Cisco 7500 series router, or a Cisco 7200 router. The TN3270 server is very different from the TN3270 terminal emulation access feature described in the "Configuring Dial-In Terminal Services" chapter of the Cisco IOS Dial Services Configuration Guide:Terminal Services. |
For details about configuring the TN3270 server on a CMCC adapter, see the "Configuring the TN3270 Server" chapter in this publication.
Posted: Thu Jul 20 10:30:58 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.