|
|
Module 6 of the Cisco IOS Documentation suite discusses the following software componenets:
This overview chapter gives a high-level description of each technology. For configuration information, refer to the appropriate chapter in this module.
Cisco IOS software supports transparent and source-route transparent bridging for Ethernet, Fiber Distributed Data Interface (FDDI), and serial media, and supports SRT bridging for Token Ring media. In addition, Cisco supports all of the mandatory Management Information Base (MIB) variables specified for transparent bridging in RFC 1286.
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.
Transparent bridging is....MARY GIVE US A ONE LINER HERE.
Cisco access servers and routers can be configured to serve as both multiprotocol routers and MAC-level bridges, bridging any traffic that cannot otherwise be routed. For example, a router/bridge routing the Internet Protocol (IP) can also bridge Digital's LAT protocol or NetBIOS traffic.
Remote bridging over synchronous serial lines is also supported between our routers and access servers. As with frames received on all other media types, the dynamic learning and any filtering is applied 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's transparent bridging software implementation has the following features:
Cisco routers and access servers also support transparent bridging on Token Ring interfaces that are capable of supporting SRT bridging. Source-route bridging enables our router/access server/bridge 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 is allowed to 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 0-1) 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.
Unlike transparent spanning-tree bridging, which requires time to recompute topology in the event of failures, source-route bridging allows multiple, active paths through the network, which provides for more timely switches to alternate routes in the event of failure. Most importantly, source-route bridging places the burden of transmitting frames with the end stations by allowing them to determine the routes the frames take.
Cisco's source-route bridging software implementation has the following features:
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 using the IEEE spanning-tree protocol, the bridge cooperates with other bridges complying to the draft SRT bridging specification 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. Note that in this configuration, all of your Token Ring transparent bridges must be Cisco routers or access servers. 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) will be transparently bridged. Packets with a RIF (RII = 1) are passed to the source-route bridging module for handling. Note that an SRT-capable Token Ring interface can have both source-route bridging and transparent bridging enabled at the same time. However, when running SRT bridging, frames that did not have a RIF when they were produced by their generating host will never gain a RIF, and frames that did have a RIF when they were produced will never lose that RIF.
When bridging between Token Ring and other media, certain packet transformations must occur. 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 higher-layer packet format, logical link control (LLC), while Ethernet supports two (LLC and Ethernet). The transformation of LLC frames between media is quite simple; a length field is either created (when going to non-Token Ring) or removed (when going to Token Ring). When an Ethernet format frame must go to Token Ring, it is translated into a 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 0000F8. Likewise, when such a packet in LLC-1 format is going to be bridged onto Ethernet media, it is translated back into Ethernet format. You can determine the OUI type used when transporting Ethernet Type II frames over other media.
Cisco IOS software supports remote source-route transparent bridging for Ethernet, Fiber Distributed Data Interface (FDDI), and serial media, and supports SRT bridging for Token Ring media. Cisco IOS software also supports its own version of DLSw.
Cisco IOS software also supports, DLSw, an alternative to source-route bridging (SRB) which addresses the following limitations of SRB:
Because these limitations occur when SRB is extended across a wide-area network (WAN), DLSw is typically used to transport SNA and NetBIOS across a WAN.
Cisco's remote source-route bridging software implementation includes the following features:
While source-route bridging involves bridging between Token Ring media only, RSRB involves multiple router/access server/bridges separated by non-Token Ring network segments. Figure 0-2 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 local-area network (LAN) internetworks by encapsulating nonroutable SNA and NetBIOS protocols within routable IP protocols. It is a means of transporting SNA and NetBIOS traffic over an Internet Protocol (IP) network.
The DLSw standard, documented in RFC 1795, defines the switch-to-switch protocol used between DLSw routers and access servers and defines a mechanism to terminate data link control connections locally and multiplex the traffic from the data link control connections onto a Transmission Control Protocol (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 route information field (RIF) be terminated at the DLSw router or access server. 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 keep track of 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 management information base (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 or access server 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 or access servers 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 0-4 shows a peer table of preferred (Pref) and capable (Cap) routes.
The Cisco IOS software supports serial tunneling (STUN) and block serial tunneling (BSTUN). Our block serial tunnel (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 0-5 shows the difference between passthrough mode and local acknowledgment mode.
The upper half of Figure 0-5 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 0-5 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 Synchronous Data Link Control (SDLC) protocols provide data link-level support for higher-level network protocols and features such as SDLLC and remote source-route bridging (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 amount 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 Systems Network Architecture (SNA) link-layer protocol for wide-area network (WAN) links. SDLC defines two types of network nodes: primary and secondary. Primary nodes poll secondary nodes in a predetermined order. Secondaries then transmit if they have outgoing data. When configured as primary and secondary nodes, our devices are established as SDLC stations.
You do not need to configure LLC2 because it is already enabled on Token Ring interfaces. You can change the default settings of LLC2 parameters as needed. To support SDLC, you need to configure the Cisco IOS software to act as a primary or secondary SDLC station. You also can change default settings on any of the SDLC parameters listed. Configuration examples for both LLC2 and SDLC are given at the end of the chapter.
The following features use LLC services:
The Cisco IOS software includes the following media translation features which 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 Logical Link Control, Type 2 (LLC2) and Synchronous Data Link Control (SDLC) at the link layer.
Systems Network Architecture (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 0-7 illustrates how SDLLC provides data link layer support 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 of 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) also 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 or access server's serial interface. When the Token Ring host sends out explorer packets with the SDLLC VTRA as the destination address in the Media Access Control (MAC) headers, the router or access server configured with that SDLLC VTRA intercepts the frame, fills in the SDLLC VRNA and the bridge number in the routing information field (RIF), and then sends the response back to the Token Ring host. A route is then established between the Token Ring host and the router or access server. After the Cisco IOS software performs the appropriate frame conversion, it uses this route to forward frames to this serial device.
DSPU is a software feature that enables the router or access server 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 or access server.
Because you define the downstream PUs at the router or access server 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 or access server also reduces network traffic on the wide-area network (WAN) by limiting the number of sessions that must be established and maintained with the host. The termination of downstream sessions at the router or access server 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 both 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 0-8 shows a router functioning as a DSPU concentrator.
Typically, a router or access server 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 or access server 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 or access server and its upstream host are completely independent of the SSCP sessions established between the router or access server 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 0-9 illustrates the SNA perspective of DSPU.
Because Frame Relay offers cost-effective means of transporting multiple protocols on a wide-area network (WAN), IBM now supports Frame Relay multiprotocol encapsulation functions on a wide range of IBM devices.
Management Service Point Support in FRAS allows the de facto SNA Network Management application NetView to manage Cisco routers and access server 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.
The multiprotocol encapsulation specification is described in RFC 1490 and FRF.3 Agreement from the Frame Relay Forum (FRF).
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 0-10.
Our Frame Relay Access support consists of a router or access server acting as a Frame Relay Access Device (FRAD) for Synchronous Data Link Control (SDLC), Token Ring, and Ethernet attached devices over a Frame Relay Boundary Network Node (BNN) link. Frame Relay access support allows the router or access server 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 or access server through SDLC, Token Ring or Ethernet links. The router or access server acting as a FRAD is connected to the NCP or AS/400 through a public or private Frame Relay network, as illustrated in Figure 0-11.
The frame format used to communicate 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 logical link is used to provide 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.
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:
This section describes some of the components of an APPN network, and reviews some 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 accessible unit (NAU). A NAU is assigned an 8 character name and an 8 character network identifier which are used to uniquely identify the unit. Examples of NAUs are Logical Units, Physical Units, Control Points and System Services Control Points.
An 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 meaningful communication in SNA; all end user data traffic communicates through this session type.
A Dependent LU (DLU) requires the services of a VTAM host acting as System Services Control Point (SSCP) to participate in an SNA network. The SSCP must establish connections with each dependent LU before it 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 PU as the representation of the physical device. It is the component that 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 only support 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 larger, complex networks.
A 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 are used to distinguish different levels of networking capabilities. This section describes APPN node types.
A 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:
A LEN node predates APPN but is able to interoperate with an APPN network. Because there is no CP-CP session between a LEN node and its network node, resources at the LEN node must be defined at the NN, reducing dynamic resource discovery capabilities.
An EN is a PU2.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 may be established through any of the connected network nodes, although only one network node may be its network node server at any one time.
An NN implements the APPN extensions to the PU2.1 architecture that allow it to provide intermediate routing services to LEN nodes and ENs.
An NN contains a Control Point to manage:
An NN provides the following network services:
An NN may be a session end point or an intermediate system.
A Network Node Server is a network node providing 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 concepts 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 may be triggered manually via EXEC commands.
A link is defined as both the link stations within the 2 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 2 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 allows initial establishment of communication between nodes. It is dependent of the data link control (DLC) chosen and may not be required for some DLC types. For switched connections, one may think of "dial" and "answer" procedures. In an X.25 network this would be the establishment of a virtual circuit. Once the connect phase has completed, the 2 nodes are able to exchange and establish node characteristics via XID exchanges.
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 XID3 exchange, it is determined which link station shall become primary and which is secondary on the link. The 2 link stations compare the XID3 values for node identifier (block number plus ID number). If the link-stations are defined to 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 has completed successfully, CS creates a new path control instance and instructs the Address Space Manager (ASM) to activate a new address space. Then CS notifies Topology and Routing Services (TRS) that a TG has become active so the APPN topology can be updated. Finally, if a CP-CP session is to be activated, CS notifies SS, who then activates the CP-CP session.
After the link is established, the nodes will 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 is responsible for determining which of the network nodes to which it is attached will be used for a CP-CP session. It indicates its choice for network node server by sending BIND to the CP on the adjacent NN. The NN then indicates its acceptance by sending BIND for a second LU6.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, the highest of the 4 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, registration of the local LUs is performed.
APPN maintains a structure which represents a map of the APPN network as known to this node. Topology and Routing Service (TRS) is the APPN component responsible for maintaining the topology, which is often called 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 network node server on APPN search requests and replies. The TG information is passed to the NN server when a route is requested, so the NN will be able to 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 end nodes and TGs.
Figure 0-12 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 0-13 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 in turn propagates the TDU to its adjacent NNs until the network topology database is again replicated.
For each NN, certain properties are specified in the TDB. Each node and TG in a network topology database is assigned a unique resource sequence number (RSN). These are incremented to the next even value whenever the owning network node creates a Topology Database Update (TDU) for that resource. TG database entries include an indicator of whether CP-CP sessions are supported, TG weight, TG status (operative or inoperative), the TG number, partner node information and TG characteristics, such as cost per byte, cost per connect time, security level, etc.
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 0-14, 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. Since it will have the same RSN and information, those TDUs will be discarded.
In Figure 0-15, TG6 is activated between NN4 and NN3. TDUs are exchanged between the 2 nodes, so each 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 management of 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. Directory Services is invoked to locate a session partner, and Topology Services is invoked to compute an optimal route to the session partner once it has been located.
Each APPN network resource must, at a minimum, be defined on the node where the resource exists. Once the resource is defined it can be found through network searches. Optionally, the resource location may be defined in other nodes to optimize Directory Services search logic.
Registered directory entries are created dynamically in the local directory of the NN. These represent local LUs of an adjacent EN, for which the NN is providing network node server function.
Cached directory entries are added dynamically, 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 will be 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, permitting 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 Topology and Routing Services is responsible for the computation of 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 Class of Service (COS) definitions to obtain the necessary information necessary to perform a route computation.
While multiple routes may be available between an origin and a destination, the best route is selected (see Figure 0-16). Selection is made through use of the COS to identify the least-cost path that provides the desired level of service.
When a session is requested, Directory Services is responsible for locating the target resource, and TRS is responsible for selecting a route.
When the origin LU requests a session, it specifies or defaults a mode to use for the session. Among other things, the mode is used to assign a COS to this session request. Acceptable COS characteristics are compared to node and TG characteristics as configured 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 would 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 (LAN the least, satellite the most), and 3 user-defined fields that are user assignable.
Node properties include route additional resistance (RAR) and a congestion indicator.
The COS table can contain multiple entries meeting the criteria, some more acceptable than others. The COS table allows the assignment of 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're 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 how many 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. By specifying a node is a member of a connection network, it may 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 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 onto the same media to the target end node, is an inefficient use of both the network node and the transmission media. Alternatively, APPN links could 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 requiring 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 (local form session identifier or LFSID) carried in the BIND, 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 only contain 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 local significance only.
A Dependent LU (DLU) is an LU that depends on the System Services Control Point (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 LU6.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 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.
Dependent LU Requester is the client half of Dependent LU Requester/Server. The Dependent LU Server (DLUS) is currently implemented in IBM's VTAM version 4.2.
There are three main concepts in DLUS/DLUR:
The DLUR function can reside on an EN or NN that actually owns the dependent LUs. In addition, as in the case for Cisco's implementation, the DLUR can exist in a network node which offers its DLUR services to PU type 2.0 and PU type 2.1 nodes which connect to the DLUR. This arrangement offers consolidation of the LU6.2 control sessions (only one pair is needed for all downstream PUs that the DLUR serves). In addition, it can provide 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 those with DLUs directly attached. Once encapsulated in the LU6.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 LU6.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 Channel Interface Processor (CIP) application, which in turn supports the IBM channel attach feature.
IBM (and 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 both 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, providing 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 Transmission Control Protocol/Internet Protocol (TCP/IP) offload. The CLAW protocol improves efficiency of channel use and allows the CIP to provide the functionality of a 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 router provides mainframe connectivity to SNA network nodes. The CIP supports both ESCON Channel Adapter (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 customers to replace currently installed IBM 3172 interconnect controllers with a Cisco 7000 series router equipped with CSNA and experience no loss of functionality, and 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:
|
|
