|
|
The Bridging and IBM Networking Configuration Guide discusses the following software components:
This overview chapter gives a high-level description of each technology. For configuration information, refer to the appropriate chapter in this publication.
Cisco IOS software supports transparent bridging for Ethernet, Fiber Distributed Data Interface (FDDI), and serial media, and supports source-route transparent (SRT) bridging for Token Ring media. In addition, Cisco supports all the mandatory Management Information Base (MIB) variables specified for transparent bridging in RFC 1286.
Cisco's transparent bridging software implementation has the following features:
Cisco access servers and routers can be configured to serve as both multiprotocol routers and Media Access Control (MAC)-level bridges, bridging any traffic that cannot otherwise be routed. For example, a router routing the Internet Protocol (IP) can also bridge Digital's LAT protocol or NetBIOS traffic.
Cisco routers also support remote bridging over synchronous serial lines. As with frames received on all other media types, dynamic learning and configurable filtering applies to frames received on serial lines.
Transit bridging of Ethernet frames across FDDI media is also supported. The term transit refers to the fact that the source or destination of the frame cannot be on the FDDI media itself. This allows FDDI to act as a highly efficient backbone for the interconnection of many bridged networks. The configuration of FDDI transit bridging is identical to the configuration of transparent bridging on all other media types.
Cisco routers support transparent bridging on Token Ring interfaces that support SRT bridging. Both transparent and SRT bridging are supported on all Token Ring interface cards that can be configured for either 4- or 16-MB transmission speeds.
As with all other media types, all the features that use bridge-group commands can be used on Token Ring interfaces. As with other interface types, the bridge group can be configured to run either the IEEE or Digital spanning-tree protocols. When configured for the IEEE spanning-tree protocol, the bridge cooperates with other SRT bridges and constructs a loop-free topology across the entire extended LAN.
You can run the Digital spanning-tree protocol over Token Ring as well. Use it when you have other non-IEEE bridges on other media and do not have any SRT bridges on Token Ring. In this configuration, all the Token Ring transparent bridges must be Cisco routers. This is because the Digital spanning-tree protocol has not been standardized on Token Ring.
As specified by the SRT bridging specification, only packets without a routing information field (RIF) (RII = 0 in the SA field) are transparently bridged. Packets with a RIF (RII = 1) are passed to the source-route bridging module for handling. An SRT-capable Token Ring interface can have both source-route bridging and transparent bridging enabled at the same time. However, with SRT bridging, frames that did not have a RIF when they were produced by their generating host never gain a RIF, and frames that did have a RIF when they were produced never lose that RIF.
Bridging between Token Ring and other media requires certain packet transformations. In all cases, the MAC addresses are bit-swapped because the bit ordering on Token Ring is different from that on other media. In addition, Token Ring supports one packet format, logical link control (LLC), while Ethernet supports two formats (LLC and Ethernet).
The transformation of LLC frames between media is simple. A length field is either created (when the frame is transmitted to non-Token Ring) or removed (when the frame is transmitted to Token Ring). When an Ethernet format frame is transmitted to Token Ring, the frame is translated into an LLC-1 "SNAP" packet. The destination service access point (DSAP) value is AA, the source service access point (SSAP) value is AA, with the organizational unique identifier (OUI) value is 0000F8. Likewise, when a packet in LLC-1 format is bridged onto Ethernet media, the packet is translated into Ethernet format.
Problems currently occur with the following protocols when bridged between Token Ring and other media: Novell IPX, DECnet Phase IV, AppleTalk, Banyan VINES, XNS, and IP. Further, problems can occur with the Novell IPX and XNS protocols when bridged between FDDI and other media. We recommend that these protocols be routed whenever possible.
Our bridging software includes source-route bridging (SRB) capability. A source-route bridge connects multiple physical Token Rings into one logical network segment. If the network segment bridges only Token Ring media to provide connectivity, the technology is termed source-route bridging. If the network bridges Token Ring and non-Token Ring media is introduced into the bridged network segment, the technology is termed remote source-route bridging (RSRB).
Source-route bridging enables our routers to simultaneously act as a Level 3 router and a Level 2 source-route bridge. Thus, protocols such as Novell's Internetwork Packet Exchange (IPX) or Xerox Network Systems (XNS) can be routed on Token Rings, while other protocols such as Systems Network Architecture (SNA) or NetBIOS are source-route bridged.
Source-route bridging technology is a combination of bridging and routing functions. A source-route bridge can make routing decisions based upon the contents of the Media Access Control (MAC) frame header. Keeping the routing function at the MAC, or Level 2, layer allows the higher-layer protocols to execute their tasks more efficiently and allows the local-area network (LAN) to be expanded without the knowledge of the higher-layer protocols.
As designed by IBM and the IEEE 802.5 committee, source-route bridges connect extended Token Ring LANs. A source-route bridge uses the routing information field (RIF) in the IEEE 802.5 MAC header of a datagram (see Figure 2) to determine which rings or Token Ring network segments the packet must transit. The source station inserts the RIF into the MAC header immediately following the source address field in every frame, giving this style of bridging its name. The destination station reverses the routing field to reach the originating station.
The information in a RIF is derived from explorer packets generated by the source node. These explorer packets traverse the entire source-route bridge network, gathering information on the possible paths the source node might use to send packets to the destination.
Transparent spanning-tree bridging requires time to recompute a topology in the event of a failure; source-route bridging, which maintains multiple paths, allows fast selection of alternate routes in the event of failure. Most importantly, source-route bridging allows the end stations to determine the routes the frames take.
Cisco's source-route bridging implementation has the following features:
In contrast to SRB, which involves bridging between Token Ring media only, RSRB involves multiple routers separated by non-Token Ring network segments.
Cisco's RSRB software implementation includes the following features:
Figure 3 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.
DLSw+ is Cisco's implementation of DLSw, an SNA-over-IP routing standard that helps to integrate SNA and LAN internetworks by encapsulating nonroutable SNA and NetBIOS protocols within routable IP. DLSw is a means of transporting SNA and NetBIOS traffic over an IP network. DLSw is an alternative to SRB and addresses the following limitations of SRB:
Because these limitations occur when SRB is extended across a WAN, DLSw is typically used to transport SNA and NetBIOS across a WAN.
The DLSw standard, documented in RFC 1795, defines the switch-to-switch protocol between DLSw routers. The standard also defines a mechanism to terminate data link control connections locally and multiplex the traffic from the data link control connections onto a TCP connection. The standard always calls for the transport protocol to be TCP and always requires that data link control connections be locally terminated (the equivalent of our local acknowledgment option). The standard also requires that the SRB RIF be terminated at the DLSw router. The standard describes a means for prioritization and flow control and defines error recovery procedures that assure data link control connections are appropriately disabled if any part of their associated circuits breaks.
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 both capable or preferred DLSw partners for either backup or load-balancing purposes. It 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 data link control flow control. Finally, the MIB is documented under a separate RFC.
DLSw+ includes the following features:
DLSw+ includes enhancements in the following areas:
DLSw+ operates in three modes:
Some enhanced DLSw+ features are also available when a Cisco router is operating in standards compliance mode with another vendor's router. In particular, enhancements that are locally controlled options on a router can be accessed even though the remote router does not have DLSw+. These include location learning (the ability to determine if a destination is on a local LAN before sending "canureach" frames across a WAN), explorer firewalls, and media conversion.
One significant factor that limits the size of Token Ring internetworks is the amount of explorer traffic that traverses the WAN. DLSw+ includes the following features to reduce the number of explorers:
The transport connection between DLSw+ routers can vary according to the needs of the network and is not necessarily tied to TCP/IP as the DLSw standard is. We support three different transport protocols between DLSw+ devices:
DLSw+ offers enhanced availability by maintaining a peer table of multiple paths to a given MAC address or NetBIOS name (where a path is either a remote peer or a local port). The Cisco IOS software maintains a preferred path and one or more capable paths to each destination. The preferred peer is either the peer that responds first to an explorer frame or the peer with the least cost. The preferred port is always the port over which the first positive response to an explorer was received. If the preferred peer to a given destination is unavailable, the next available capable peer is promoted to the new preferred peer. No additional broadcasts are required, and recovery through an alternate peer is immediate.
Maintaining multiple paths per destination is especially attractive in SNA networks. A common technique used in the hierarchical SNA environment is assigning the same MAC address to different Token Ring interface couplers (TICs) on the IBM front-end processors (FEPs). DLSw+ ensures that duplicate TIC addresses are found, and if multiple DLSw+ peers can be used to reach the FEPs, they are all cached.
The way that multiple capable peers are handled with DLSw+ can be biased to meet either of the following network needs:
Figure 5 shows a peer table of preferred (Pref) and capable (Cap) routes.
DLSw+ can be used as a "virtual" data link control for other SNA features in the Cisco IOS software, including:
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.
To use DLSw+ as a "virtual" data link control requires a feature called virtual data link control (VDLC). Higher-layer protocols (data-link users such as LNM, DSPU, and SNA service point) use virtual data link control to run over DLSw+ and communicate with one another through Cisco routers. Virtual data link control provides this service to data-link users with minimum change to the data-link users themselves, as long as they comply with Cisco link services interface (CLSI) requirements.
In Figure 6, DSPU and DLSw+ use Token Ring and Ethernet, respectively, as "real" data link controls, and use virtual data link control as a virtual data link control to communicate between themselves. When one of the high-layer protocols passes data to virtual data link control, virtual data link control must pass it to a higher-layer protocol; nothing leaves virtual data link control without going through a data-link user.
The Cisco IOS software supports serial tunnel (STUN) and block serial tunnel (BSTUN). Our BSTUN implementation enhances Cisco 2500 series, Cisco 4000 series, and Cisco 4500 series routers to support devices that use the Binary Synchronous Communication (BSC) data link protocol.
STUN operates in two modes: passthrough and local acknowledgment. Figure 7 shows the difference between passthrough mode and local acknowledgment mode.
The upper half of Figure 7 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 pass-through of all SDLC traffic, including control frames.
The lower half of Figure 7 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.
Our STUN implementation provides the following features:
The Logical Link Control, type 2 (LLC2) and SDLC protocols provide data link-level support for higher-level network protocols and features such as 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.
LLC2 and SDLC package data in frames. LLC2 and SDLC stations require acknowledgments from receiving stations after a set amount of frames have been sent before sending further data. The tasks described in this chapter modify default settings regarding the control field of the data frames. By modifying the control field parameters, you can determine the number of acknowledgments sent for frames received and the level of polling used to determine available stations. In this manner, you can set the amount of resources used for frame checking and optimize the network load.
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.
Figure 9 illustrates how SDLLC provides data link layer support for SNA communication.
The SDLLC software allows a physical unit (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 provides translation between the two media to be 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 (SDLLC VRN) must be assigned to each SDLLC device on a serial line. (The SDLLC VRN 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 VRN 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 VRNA 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; however, 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.
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 10 illustrates how QLLC conversion provides data link layer support for SNA communication.
As shown in Figure 11, 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 12, the QLLC conversion feature eliminates the need to install the X.25 software on local IBM equipment. A device that is locally attached to a Token Ring network can communicate through a router that is running the QLLC Conversion feature with a remote device that is attached to an X.25 network using QLLC. Typically, the locally attached device is a front-end processor (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 13, 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 14 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 14, 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 15 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 1 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 both of the following two 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 Support" chapter.
Downstream Physical Unit (DSPU) is a software feature that enables the router to function as a physical unit (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.
Our 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 16 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 17 illustrates the SNA perspective of DSPU.
Because Frame Relay offers a cost-effective means of transporting multiple protocols on a WAN, IBM now supports Frame Relay multiprotocol encapsulation functions on a wide range of IBM devices.
Management service point support in Frame Relay Access Support (FRAS) allows the de facto 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 at once.
FRAS includes boundary access node (BAN) support. The BAN uses Frame Relay RFC1490 802.5 bridged format to transport SNA traffic between the 3745/3746-900 and LAN or SDLC attached downstream PUs.
The multiprotocol encapsulation specification is described in RFC 1490 and FRF.3 Agreement from the Frame Relay Forum.
RFC 1490 specifies a standard method of encapsulating multiprotocol traffic with data link (Level 2 of the OSI model) framing.The encapsulation for SNA data is specified in the FRF.3 Agreement.
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 18.
Our Frame Relay access support consists of a router acting as a Frame Relay Access Device (FRAD) for SDLC, Token Ring, and Ethernet attached devices over a Frame Relay Boundary Network Node (BNN) link. Frame Relay access support 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 19.
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.
The Cisco IOS software is responsible for terminating the local data link control (DLC) frames (such as SDLC and Token Ring frames) and for modifying the DLCs 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 permanent virtual circuit (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 DLC frames to the downstream devices.
Advanced Peer-to-Peer Networking (APPN) is the second generation of SNA. APPN provides support for client/server applications and offers more dynamics than traditional hierarchical SNA, such as dynamic directory and routing services.
Cisco's APPN implementation includes the following features:
The following section describes some of the components of an APPN network and reviews basic SNA terminology. The section identifies and compares node types and compares APPN with subarea SNA.
The basic component of an SNA network, subarea or APPN, is the network addressable unit (NAU). A NAU is assigned a unique eight-character name and an eight-character network identifier. Examples of NAUs are LUs, PUs, control points (CPs)and system services control points (SSCPs).
A logical unit (LU) is an interface that enables end users to gain access to network resources and communicate with each other. Examples of LUs are printers, terminals, and applications. LUs communicate with each other via LU-LU sessions. The LU-LU session is the basis of communication in SNA; all end user data traffic communicates through this session type.
To participate in an SNA network, a DLU requires the services of a VTAM host acting as an SSCP. The SSCP must establish connections with each DLU before the DLU is able to participate in the network. Dependent LUs, such as 3270 terminals, are only capable of maintaining a single LU-LU session at any one time.
An Independent LU (ILU) does not require the services of an SSCP to participate in an SNA network. In addition, an ILU can establish sessions to more than one partner in the network, and can have multiple parallel sessions with the same partner LU. Applications implementing Advanced Program-to-Program Communications (APPC) are examples of independent LUs.
SNA defines a physical unit (PU) as the representation of the physical device. The PU manages and monitors the resources (such as attached links and adjacent link stations) associated with an SNA node.
Physical Unit Type 2 (PU2), the legacy physical unit, can support only dependent LUs and requires the services from a VTAM host to perform network functions.
Physical Unit Type 2.1 (PU2.1), also known as a type 2.1 node, offers peer node capabilities in an SNA environment. A PU2.1 can support both dependent and independent LUs. In addition, a PU2.1 can support a control point, which is central to APPN networking.
APPN extends the PU T2.1 architecture to provide dynamic discovery and definition of resources and routing capabilities for large, complex networks.
A control point (CP) identifies the networking components of a PU Type 2.1 node. In APPN, CPs are able to communicate with logically adjacent CPs by way of CP-CP sessions. Almost all APPN functions, including searches for network resources and discovery of network topology, use CP-CP sessions as the means of communication between nodes.
In an APPN network, different node types distinguish different levels of networking capabilities. This section describes APPN node types.
A Low-Entry Networking (LEN) node, sometimes called a LEN end node, is a PU 2.1 without APPN enhancements. The following are some of the characteristics of a LEN node:
LEN nodes predate APPN but are able to interoperate with an APPN network. Because there is no CP-CP session between a LEN node and its NN, resources at the LEN node must be defined at the NN, reducing dynamic resource discovery capabilities.
An EN is a PU 2.1 that includes the APPN support necessary to gain full access to an APPN network. However, an EN is not capable of performing in an intermediate role when routing APPN sessions. The following are the characteristics of an EN:
Because an EN lacks full APPN routing capability, it might be thought of as an application host or point of user access. The EN establishes CP-CP sessions with its NN server, so topology and directory information can be exchanged dynamically, eliminating the need to define resources on the NN. The EN may connect to multiple network nodes and LU-LU sessions can be established through any of the connected network nodes, although only one network node can be its network node server at any one time.
An NN implements the APPN extensions to the PU 2.1 architecture that allow it to provide intermediate routing services to LEN nodes and ENs. An NN contains a CP to manage it own resources and the ENs and LEN nodes in its domain.
An NN provides the following network services:
An NN may be a session end point or an intermediate system.
An NN Server is a network node that provides resource location and route selection services for the LEN nodes, ENs, and LUs it serves. The nodes served, ENs or LEN nodes, are defined as being in the network node server's domain.
This section describes the basic components of APPN and how they interact to provide APPN networking functions.
The configuration services (CS) component of an APPN node manages local interfaces and connections to the APPN network. CS controls the ports and link stations on the node. A port defines a connection to a transport media accessible to APPN, while a link station identifies the addressing information and characteristics of a connection with another node.
When two APPN nodes connect, the following activities occur:
The entire connection phase may be configured to occur automatically, or the connection can be initiated manually via EXEC commands.
A link is defined as both the link stations within the two nodes it connects and the link connection between the nodes. A link station is the hardware or software within a node that enables the node to attach to, and provide control over, a link connection. A link connection is the physical medium over which data is transmitted. A transmission group, in legacy SNA, may consist of one or more links between two nodes. However, in the APPN architecture, transmission groups are limited to a single link. It is therefore common in APPN to use the terms link and transmission groups interchangeably.
The connection phase in APPN begins with link activation, which initiates communication between nodes. It is independent of the DLC chosen and may not be required for some DLC types. For switched connections, the connection phase is similare to "dial" and "answer" procedures. In an X.25 network the connection phase would be the establishment of a virtual circuit. When the connect phase is complete, the two nodes can exchange and establish node characteristics through exchange identification (XID).
The exchange of XIDs allows a node to determine if the adjacent station is active and to verify the identity of the adjacent node. Node identification fields, including the CP name, will be exchanged. This information exchange allows, for example, a node to correlate an incoming connection with a link station definition on the node.
During XID exchange, primary and secondary link stations are determined. The two link stations compare the XID node identifier values (block number plus ID number). If the link stations are defined as negotiable, then the higher node ID becomes primary. If the nodes have the same node ID, each generates a random number and the node with the higher random number becomes primary. The result of the primary-secondary role negotiation determines which node will send the mode-setting command--Set Normal Response Mode (SNRM) for SDLC, Set Asynchronous Balanced mode (SABM) for X.25, and so on.
After the link activation XID exchange is complete, CS creates a new path control and instructs the Address Space Manager (ASM) to activate a new address space. Then CS notifies Topology and Routing Services (TRS) that a transmission group (TG) has become active so the APPN topology can be updated. Finally, if a CP-CP session is to be activated, CS notifies SS. SS then activates the CP-CP session.
After a link is established, the nodes determine if CP-CP sessions should be established. Between network nodes, CP-CP sessions are normally activated on the first link to become active between the nodes. An EN determines which of the NNs will be used for a CP-CP session. The EN indicates which NN is the server by sending a request to activate a session, known as a BIND, to the CP on the adjacent NN. The NN accepts by sending BIND for a second LU 6.2 session, completing the CP-CP session pair. Each node uses one session to send CP-CP communication data, while the other is reserved for receiving data from the partner node.
CPSVCMG is the class of service (COS) used for CP-CP sessions. It indicates a transmission priority of network, which is the highest of the four transmission priorities in APPN.
When the CP-CP session is established, the CPs exchange capabilities, and, in the case of EN to NN CP-CP sessions, register the local LUs.
APPN maintains a map of the APPN network as known to a particular node. TRS is the APPN component responsible for maintaining the topology database.
There are two types of information in a topology database: local topology and network topology.
An EN uses the information in its local topology database to send local TG information to the NN server on APPN search requests and replies. The TG information is passed to the NN server when a route is requested, so the NN can select the best TG from the EN to one of its adjacent NNs. In a NN, the local topology database includes information about the attached ENs and TGs.
Figure 20 shows the local topology as it is known to EN A, NN2, and EN B.
Network topology contains information on all network nodes in the APPN network as well as the TGs interconnecting them. Every NN maintains a fully replicated copy of the network topology database. Figure 21 illustrates an APPN network topology.
The network topology database is built from information about the local NN and its TGs to other NNs, and from Topology Database Updates (TDUs) received from adjacent NNs. TDUs are exchanged whenever NNs establish CP-CP sessions with each other. As updates occur in NNs or TGs between NNs, the owning NN sends a TDU to its adjacent NNs, which propagates the TDU to its adjacent NNs until the network topology database is again replicated.
For each NN, certain properties are specified in the topology database. Each node and TG in a network topology database is assigned a unique resource sequence number. These numbers are incremented to the next even value whenever the owning network node creates a TDU for that resource. TG database entries include indicate whether CP-CP sessions are supported, and include the TG weight, TG status (operative or inoperative), TG number, partner node information, and TG characteristics such as cost per byte, cost per connect time, and security level.
TDUs provide updated information to NNs about the node itself and information about all locally owned TGs to other network nodes. TDUs can be triggered by changes in node or TG characteristics.
TRS broadcasts TDUs containing local node information every five days to prevent other network nodes from discarding valid information, which occurs after 15 days with no update. This 15-day cleanup of the database is called garbage collection.
In Figure 22, NN3 adds itself to the network. NN3 forwards information about itself to NN1. NN1 forwards the information to NN2 and NN4. NN2 and NN4 then forward a second TDU to each other. Because they will have the same RSN and information, the second TDUs will be discarded.
In Figure 23, TG6 is activated between NN4 and NN3. TDUs are exchanged between the two nodes, so each node can build a new topology database. New information is propagated to adjacent nodes once NN4 and NN3 have updated topology databases. TG6 could be active, but with no CP-CP session established. The TG will still be included in the network topology and forwarded, so that path can be used for sessions.
Directory services (DS) is the APPN component responsible for managing the directory database and searching for network resources throughout the APPN network. The directory database should not be confused with the topology database. The directory database maintains information about resource names and their owners, while the topology database maintains a network map of NNs and TGs. DS locates a session partner. Topology service computes an optimal route to the session partner when it has been located.
Each APPN network resource must, at a minimum, be defined on the node where the resource exists. When the resource is defined, it can be found through network searches. Optionally, the resource location may be defined in other nodes to optimize DS search logic.
Registered directory entries are created dynamically in the local directory of the NN. These entries represent local LUs of an adjacent EN for which the NN is providing network node server function.
Cached directory entries are added dynamically and are based on the results of previous searches. A cache entry allows the node to attempt a directed search straight to the destination resource. If a cache entry does not exist, or the entry is incorrect, a broadcast search is issued to query each NN in the network for the destination resource. Each cache entry is verified before use to make sure the resource is still available. If the resource is not found, a broadcast search is attempted.
Some implementations, including Cisco's, support safe store of the directory cache. The cache entries in a network node's directory database are periodically written to a permanent storage medium. Safe store permits faster access (after a network node failure or initial power-on) by eliminating network broadcast searches for safe-stored resources.
Each APPN session is assigned a route on which the data path for this session will travel. APPN TRS is responsible for computing a route for an LU-LU session. A route is an ordered sequence of nodes and TGs that represents a path from an origin node to a destination node. TRS uses the topology database and its COS definitions to obtain the information necessary to perform a route computation.
While multiple routes may be available between an origin node and a destination node, the best route is selected (see Figure 24). The lowest-cost path that provides the desired level of service is selected.
When a session is requested, DS locates the target resource, and TRS selects a route.
When the origin LU requests a session, it either specifies a mode or uses a default mode for the session. The mode determines a COS for this session request. Acceptable COS characteristics are compared to node and TG characteristics to select the best route.
A COS table entry specifies transmission priority, COS name and one or multiple rows of COS characteristics that are acceptable for that COS. Note that traffic on sessions with the same COS can only flow at the same transmission priority. You need a separately named entry to achieve a different priority on the same route.
TG characteristics include link speed, cost per connect time, cost per byte, security class (7 levels), propagation delay, and three user-defined fields.
Node properties include route additional resistance (RAR) and a congestion indicator.
The COS table can contain multiple entries meeting the criteria. Some entries are more acceptable than others. The COS table lets you assign weight to each entry to differentiate the value of each entry. For each possible route, compare the characteristics of the component nodes and transmission groups to the ranges of acceptable characteristics as defined in the COS table for that COS. For each NN or TG the characteristics are compared to see if they are within the range of tolerance. If so, a weight is assigned to each node and each TG and is added to the total weight for that particular route.
When all routes are weighed, the one with the lowest weight is selected. Ties are broken by random selection.
Route selection is a complex process and, where multiple routes are available, may involve considerable overhead. To reduce this overhead, TRS uses routing trees to store the best route path to each node in the network for a specific COS. You may configure the number of routing trees the node will maintain at any one time.
Connection networks provide extensions to the APPN route calculation algorithm to simplify definitions and enhance connectivity on shared transport media. If you specify a node as a member of a connection network, that node can establish a direct connection, when needed, between itself and any other member of the connection network.
For example, on one Token Ring, there may be 50 end nodes with links and a CP-CP session active to the same network node. The end nodes may communicate with each other through the network node, but this data path, which routes data through the network node then back on the same media to the target end node, is an inefficient use of both the network node and the transmission media.
Alternatively, APPN links can be configured between each end node it a mesh fashion, but this would require over 1000 link definitions. Instead, each end node can be configured as a member of the same connection network. This allows APPN route calculation to calculate a route through the connection network between the two end nodes. The resulting data path is a direct connection between end nodes without a corresponding link definition on either node.
After a route is selected, a BIND session command flows from the origin LU to the destination LU over the specified route. The BIND includes:
As the BIND passes through each NN, the NN records the inbound session identifier or local form session identifier (LFSID), and assigns a new session identifier to be used on the outbound port. It also builds a "session connector" that connects the inbound session identifier with the outbound session identifier, so that it knows how to forward subsequent packets on this session. The session connector also stores information carried in the BIND, such as segmentation values and transmission priority, so that other components, such as path control, will be able to utilize the information on session traffic.
No subsequent data packets contain any routing information--they contain only the local form session identifier. Packets are forwarded based on information in session connectors, including port and outbound LFSID. LFSIDs are swapped at each NN since they have only local significance.
A dependent LU (DLU) is an LU that depends on the SSCP in VTAM to provide services for establishing sessions. Common DLU types are DLU 0, 1, 2, and 3.
Dependent LUs originated in subarea SNA. In early APPN environments, only LU 6.2 independent LUs were supported. The PU supporting dependent LUs still required a logical link directly to a subarea network boundary function (VTAM or NCP) in order to operate. Dependent LU Requester (DLUR) provides the extensions to APPN necessary to allow dependent LUs to interoperate in an APPN network and removes the restriction that dependent LUs must have a direct connection to a subarea network boundary function.
DLUR is the client half of Dependent LU Requester/Server (DLUR/DLUS). The Dependent LU Server (DLUS) is currently implemented in IBM's VTAM version 4.2.
There are three main concepts in DLUR/DLUS:
The DLUR function resides on an EN or NN that owns the dependent LUs. In addition, the DLUR exists in a network node that offers its DLUR services to PU type 2.0 and PU type 2.1 nodes which connect to the DLUR. This arrangement consolides the LU6.2 control sessions (only one pair is needed for all downstream PUs that the DLUR serves). In addition, this arrangement provides considerable cost savings over upgrading each device that owns dependent LUs to be APPN and DLUR capable.
DLUR function does not have to be active in all APPN nodes--only in those nodes with DLUs directly attached. Once encapsulated in the LU 6.2 session, the DLUR control traffic (encapsulated SSCP-PU and SSCP-LU control flows) looks like regular APPN traffic.
By providing DLUS support in VTAM, SSCP support is extended to LUs residing on nodes that are nonadjacent to the VTAM or NCP boundary function. Traditional SSCP-PU and SSCP-LU session flows are multiplexed in LU 6.2 sessions between the DLUR and DLUS.
The benefits of using the DLUS/DLUR function include
The Cisco 7000 series supports the Cisco IOS software mainframe CIP application, which in turn supports the IBM channel attach feature.
IBM (and IBM-compatible) mainframe hosts are connected to each other and to communication controllers through high-performance communication subsystems called mainframe channels. Cisco supports IBM channel attachment technologies, including the fiber-optic Enterprise Systems Connection (ESCON) channel introduced on the ES/9000 mainframe and the parallel bus-and-tag channel supported on System 370 and later mainframes.
The Cisco 7000 series configured with the CIP (and other interface processors) is an ideal connectivity hub for large corporate networks, and provides the following routing services between mainframes and LANs:
Cisco has implemented Common Link Access for Workstations (CLAW) support in the CIP, which is a link-level protocol used by channel-attached RISC System / 6000 series systems and by IBM 3172 devices running TCP/IP offload. The CLAW protocol improves channel efficiency and allows the CIP to provide the functionality of an IBM 3172 in TCP/IP environments and support direct channel attachment. The output from TCP/IP mainframe processing is a series of IP datagrams that the router can switch without modifications.
Cisco has implemented offload processing support for TCP/IP. Like the offload feature of the IBM 3172 Model 3, the TCP offload feature on the CIP is designed to remove processing cycles from the mainframe by executing the TCP protocol on the CIP card. But while the IBM 3172-3 executes TCP in an OS/2 environment, the CIP utilizes the MIPS processor and high-speed channel software to deliver vastly improved performance and scalability. The TCP/IP protocol suite runs on the CIP board and delivers routable IP frames to the Cisco 7000 series router.
CIP Systems Network Architecture (CSNA) support in a Cisco 7000 series router provides mainframe connectivity to SNA network nodes. The CIP supports both ECA and Parallel Channel Adapter (PCA) connections to an IBM mainframe using SNA network features. The CSNA feature provides an SNA LAN gateway to VTAM using a high-speed channel connection.
The CSNA feature also allows you to replace currently installed IBM 3172 interconnect controllers with a Cisco 7000 series router and experience no loss of functionality. You will, in fact, gain functionality with minimal or no changes to VTAM or site configuration.
Support for IBM channel attach requires the following hardware:
Your mainframe host software must meet the following minimum requirements:
|
|
