|
|
This chapter provides a historical perspective that shows how the SNA technology evolved to the state it is at today. Frame Relay standards and how they apply to SNA are also presented. Last, frame formats and the flow of data are discussed.
The reason that technology to carry SNA traffic over Frame Relay exists is to maintain corporate investments in IBM mainframe applications. For many corporations, a primary requirement is to never change mainframe applications. This requirement is so important that all other aspects of the networking enterprise must accommodate it. This is pervasive throughout the industry.
Figure 1-1 provides an overview of the SNA internetworking technology evolution. In the beginning there was the classic multidrop Synchronous Data Link Control (SDLC) protocol scenario. SDLC was the dominant link-layer protocol. SNA relied on SDLC to provide a guaranteed delivery service, thus avoiding the need to address mundane tasks such as monitoring line quality. In Europe and Asia, in addition to SDLC, X.25 was a very predominant transport mechanism for SNA. Like SDLC, X.25 provided the guaranteed delivery service required by SNA. Qualified Logical Link Control (QLLC) was implemented on Network Control Program (NCP) to make Virtual Telecommunications Access Method (VTAM) think that SDLC was running on the front-end processor (FEP). QLLC essentially performed SDLC-like functions over X.25. IBM provided this function in a product called X.25 NCP Packet Switching Interface (NPSI).
As technology progressed, more-reliable digital technology paved the way for new, higher-speed packet services that assumed the presence of reliable links. From these fast-packet services, frame-switching services emerged and eventually became Frame Relay as we see it today. The presence of reliable links means 99.999 percent network reliability, which is fine for datagram-based protocols (for example, IP, IPX, and AppleTalk) that have higher-layer subsystems handling guaranteed delivery. This level of reliability is not acceptable to SNA. In addition, the frame-based services needed to incorporate statistical multiplexing functionality, which was popular at the time. This feature led to what is referred to as over-subscription. By over-subscribing, networks exposed themselves to the possibility that periods of congestion could occur. Congestion results in frame loss, which is unacceptable to SNA. However, for IBM customers, the low-cost, frame-based networking service was acceptable.
To allow IBM customers to take advantage of these new low-cost, frame-switching services, a guaranteed delivery link-layer service was needed to replace SDLC and QLLC. To replace these protocols, IBM found an existing and proven LAN-based protocol to do the job. Logical Link Control, type 2 (LLC2) was chosen as the protocol to run over Frame Relay. Thus, LLC2 appeared on IBM remote cluster controllers and on NCP when it was used over Frame Relay. On NCP the feature was called BNN. BNN was designed to allow a single IBM 3270 cluster controller residing on a Frame Relay connection (virtual circuit) access to the mainframe. BNN masked any remote access peculiarities related to Frame Relay from VTAM.
BNN marked a significant event in the industry because mainframe access was now conducted over Frame Relay. Before long, many of the existing X.25 packet assembler/disassembler (PAD) vendors saw market potential for a similar device for SNA Frame Relay environments. These devices were called Frame Relay access devices (FRADs). The idea was to take a number of legacy SNA devices running, for example, legacy SDLC and connect them to a FRAD to perform a protocol conversion to the BNN formats on Frame Relay. As a result, the SNA devices appeared to NCP to be IBM 3270 cluster controllers at the remote end of the Frame Relay connections. The next step was to connect an entire LAN to the FRAD and perform the same conversion process. BNN assumes only a single device for each Frame Relay connection. To accommodate multiple devices, one had to use multiple connections (virtual circuits) or some sophisticated physical unit (PU) concentration that presented the mainframe with a single SNA device from multiple collapsed SNA devices. These techniques were more costly and complex, but they did work.
Multiple devices can be supported on a single virtual circuit using a technique called service access point (SAP) multiplexing. This multiplexing is accomplished by manually mapping the legacy Layer 2 device address (media access control [MAC] or SDLC station address) to the LLC2 SAP address on the Frame Relay WAN. The FRAD devices and the FEP can uniquely identify the legacy devices from a destination service access point/source service access point (DSAP/SSAP) pair appearing on the virtual circuit. By varying the LLC2 SAP address, multiple devices can be represented. The administrator configures a map from the LAN, SDLC, or X.25/QLLC device address to a unique LLC2 DSAP/SSAP pair. This configuration worked for small environments, but something more encompassing was needed for large enterprises with many LAN devices. (For a description of the BNN frame format, see the "SNA Internetworking Frame Formats" section.)
BAN was designed from the beginning with the FRAD capabilities in mind. Using the RFC 1490 bridged format, BAN added fields to the frame formats that allow MAC addresses to appear on the WAN along with the LLC2 SAP addresses. This additional capability was the most significant functional change introduced by BAN. The number of devices supported was virtually limitless and, because MAC addresses were passed through, no additional configuration was required on the FRAD to support multiple LAN devices. BAN did required changes to be made to NCP because new configuration would be required. However, now the industry had two major methods of accessing the mainframe over Frame Relay. (For a description of the BAN frame format, see the "SNA Internetworking Frame Formats" section.)
Today, there are more than two methods for accessing the mainframe over Frame Relay. While development was taking place on cluster controllers, NCP, and FRAD devices, similar efforts were afoot to allow SNA protocols to operate over IP-based networks. Like Frame Relay, IP is a best-effort delivery service. TCP/IP was used to furnish the guaranteed delivery requirement for SNA in these environments. Initially, Cisco delivered remote source-route bridging (RSRB), which was tremendously successful in the market. IBM, largely rejecting the SNA internetworking market at that time, had limited success with DLSw based on an earlier RFC 1434 standard implementation. The standard had so many problems that it was eventually abandoned. In these environments using DLSw, NCP never came into the picture. These bridging and switching techniques were to be implemented on a different type of general-purpose networking devices---routers.
Cisco, IBM, and the rest of the internetworking industry eventually embraced the DLSw standard and ratified RFC 1795. In a parallel effort, FRAD vendors implemented the host portion of BNN and BAN on their devices, eliminating the need to upgrade the FEPs to run BNN or BAN. Routers that route IP and carry SNA over IP on Frame Relay work well. FRADs carrying SNA over BNN or BAN and routing IP work well. As a result, there was a convergence of routing products and FRAD products and their respective markets.
Some FRAD vendors and companies implementing SNA-only technologies claim that there is a technological difference between the methods they use to carry SNA over Frame Relay and the methods that routers use. Technically, there is no difference. A Frame Relay switch, which connects to both routers and FRADs, certainly cannot distinguish between the two. The only difference lies in the background of the various vendors and the markets in which those vendors are comfortable. FRADs have evolved from vendors with backgrounds in circuit-based transmission systems or Layer 2 technologies. These vendors are more familiar with technologies like BNN, BAN, voice, and X.25. Router products have evolved from vendors with backgrounds in networking-based technologies that are media independent and function at Layer 3 and higher. FRAD marketing programs, sometimes backed by paid industry consultants, that attempt to position their products as technically superior. These issues are clearly non-technical.
Cisco, in order to remain technology-neutral, supports all of the FRAD and DLSw technologies for SNA. Because of the combination of Cisco's IP routing history, its huge customer base with an existing IP infrastructure, and the attraction of an all-IP backbone, DLSw+ has emerged as the dominant technology in Frame Relay-based networks carrying SNA protocols.
There are numerous Frame Relay standards. In addition to specifying frame formats and protocols, one of the primary objectives of Frame Relay standardization is to agree on a means of identifying multiple protocols over a single Frame Relay virtual circuit to allow interworking. The goal is to administer a common set of protocol IDs. The list of organizations employed to develop the common protocol IDs is impressive: ITU-T, ANSI, AIW, FRF, IETF, ISO, and the former CCITT. Adding to the confusion are multiple standards that basically accomplish the same thing with few end-user perceived differences. The following Frame Relay standards are considered most relevant:
Most of the standards above enumerate a set of protocol IDs referred to as network layer protocol IDs. From these works, the following two major Frame Relay internetworking specifications have emerged for SNA:
RFC 1490 covers encapsulation methods for bridging and routing multiprotocol internetworking traffic over Frame Relay. FRF 3.1 covers user-specified network layer protocol IDs for SNA not found in RFC 1490, for example NetBIOS and High Performance Routing (HPR).
For more information on standards documents, see the References appendix.
Most networking equipment today uses RFC 1490 or FRF 3.1 encapsulation methods when carrying SNA protocols over Frame Relay. A common concern about SNA internetworking is encapsulation overhead. There is little technical merit for this concern and its roots can be traced to marketing claims. The following frame formats are discussed in this section:
BNN uses the routed frame format for transporting SNA over Frame Relay although legacy SNA PU 2.0 protocols are not routable. Advanced Peer-to-Peer Networking (APPN), HPR, and SNA format indicator 4 (FID 4) subarea protocols are routable so there is some justification for the terminology. In addition, the MAC addresses are removed, which meets at least one criteria of a routed protocol. RFC 1490 defines the format of a routed frame. FRF 3.1 is used to specify the user-defined Layer 2 and Layer 3 protocol IDs commonly used today. Figure 1-2 is a diagram of the BNN frame format.
BNN, with only 12 bytes of overhead, has the lowest overhead compared to BAN, DLSw+, and DLSw+ Lite. BNN uses a network layer protocol ID set to a value indicating that CCITT Q.933 formats are used (x08). This allows an additional 4 bytes of protocol identification for Layer 2 and Layer 3. The Layer 2 protocol is set to 802.2 or LLC2 (x4c80), and the Layer 3 protocol is set to user specified (x70) and SNA peripheral (x82). These codes-points for the Layer 3 network layer protocol ID are documented in FRF 3.1.
BAN uses the bridged frame format for transporting SNA over Frame Relay, although IBM states that BAN is not bridging. This statement is a marketing ploy and has little technical merit. BAN, is at best a highly filtered bridging technology. Figure 1-3 is a diagram of the BAN frame format.
The encapsulation overhead for BAN is usually 28 bytes unless there is a Routing Information Field (RIF) present. Cisco's implementation terminates the RIF and strips it from the frame before placing the frame on the WAN. Using the protocol IDs specified in RFC 1490, the network layer protocol ID is set to Subnetwork Access Protocol (SNAP) (x80). Within the SNAP header the Organizational Unique Identifier (OUI) is set to a value of 0x0080c2, indicating bridged format, and a PID of x0009, indicating 802.5. MAC addresses are also included in the frame format. The addition of MAC addresses gives BAN a virtually unlimited capacity to support bridged devices.
DLSw+ Lite is a special consideration because it does not fall into any ratified standard. Cisco offered DLSw+ Lite to the standards organizations, but, because of a lack of customer demand beyond Cisco, there was little interest from other vendors. DLSw+ Lite uses the RFC 1490 routed format indicating user-specified IDs for Layer 2 and Layer 3 using FRF 3.1. DLSw+ Lite uses the following routed frame format: network layer protocol ID set to indicate CCITT Q.933 protocol ID (x08), 802.2 or LLC2 Layer 2 protocol (x4c80), user-specified Layer 3 protocol (x70), and SNA DLSw (x81).
The encapsulation overhead of DLSw+ Lite is 28 bytes, which is the same as BAN. Figure 1-4 shows the DLSw+ Lite frame format. DLSw+ Lite is the Frame Relay equivalent of DLSw+ direct.
The major protocols that the network designer needs to be concerned with are LLC2, NetBIOS, and HPR. NetBIOS uses LLC2, but it also uses LLC1 frames or datagrams to broadcast information about resources and to locate NetBIOS resources. Both SNA (including APPN) and NetBIOS use explorer broadcasts or multicast frames (called functional addresses in Token Ring) to locate resources. After resources are located, both protocols use LLC2 for session establishment and information transfer. HPR uses only LLC1 datagrams (unnumbered information [UI] frames). Like TCP/IP, HPR relies on higher-layer protocols, such as Rapid Transport Protocol (RTP), to guarantee delivery.
On the LAN there are basically three major categories of frame types: explorer frames, information frames, and datagrams. Explorer frames can be broken down into local explorers, all-routes explorers, single-route explorers, and directed explorers. Information frames can be broken down into supervisory frames, which are used to initiate and synchronize link-layer establishment, and information frames (I-frames), which carry data. Datagrams, or UI frames, are sent without any guarantee of delivery.
Broadcast and multicast explorers are used to locate resources. They are forwarded by bridging devices. As explorers are forwarded, the bridging devices add the input ring that the explorer came from and its bridge ID to the RIF. The bridging device then forwards the explorer through each Token Ring port configured as part of the bridging domain. The bridging domain information is derived from the source-bridge active command on the Token Ring interfaces or the bridge-group command on Ethernet interfaces. Each bridge checks the existing RIF to make sure that an explorer is not put on the same ring twice to avoid a bridging loop. When the explorer reaches the target ring, the resource or target station is contacted. The target station saves the RIF and responds directly to the originator by reversing the RIF. The originator saves the RIF on the response as well. Subsequent communication takes place using the learned RIF. Traditionally, source-route bridges do not get involved with storing ring routing information. The RIF is stored at the source end stations. Thus the process is called source-route bridging (SRB). The router facilitates value-add features such as proxy explorer, explorer firewalls, and multiring routing. A RIF cache is used on the router to implement these features, but these features are not required to perform basic source-route bridge functions.
As mentioned before, there are four types of explorers: local explorer, single-route broadcast explorer, all-routes broadcast explorer, and directed explorer. An originating end station first sends a local explorer to locate resources locally on a ring. A local explorer is never picked up by a bridging device. When the originating device is convinced that the resource cannot be found locally, it sets the source-route indicator bit in the SMAC header. Setting this bit signals locally attached bridges to pick up the frame and forward it. However, in fully connected redundant ring topologies with multiple paths to resources, this forwarding of the all-routes broadcast explorers can create broadcast storms. To reduce the impact of this phenomenon, single-route broadcast explorer frames were introduced. SNA sends all-routes broadcast and NETBIOS sends single-route broadcasts. Bridging devices forward single-route broadcast frames on a single path as determined by a spanning-tree protocol run on the bridge. Another form of explorer frame is the directed explorer. The directed explorer is commonly used by DLSw+. It contains a valid RIF and is sent directly to the resource for verification of its presence.
DLSw+ picks up all-routes and single-route explorers and unconditionally converts them to single-route explorers. This default behavior can be changed using a configuration option. DLSw+ also terminates the RIF by stripping it from the frame and storing it in the reachability cache, which is indexed by target resource identifier (MAC address or NetBIOS name) for future use. Stripping the RIF and using the reachability cache allows DLSw+ to expand source-route bridged networks beyond the maximum architectural limit of seven. Going beyond seven hops is not recommended, but the ability is present.
DLSw+ uses a protocol called Switch-to-Switch Protocol (SSP) between peers, which is specified in RFC 1795. SSP has primitives that are equivalent to Token Ring LLC or NetBIOS protocol data units. As a result, a protocol conversion takes place from LLC2 to SSP. For example, explorers are converted to SSP CANUREACH frames. SSP is encapsulated over the WAN (using, for example, TCP/IP, Fast-Sequenced Transport [FST], direct High-Level Data Link Control [HDLC], or LLC2).
Once target resources are contacted, the next step is to establish an LLC2 session with the target and then maintain that session, guarantee the delivery and sequence of frames, and maintain flow control during periods of congestion. Meeting these requirements, while sending data over a low-speed WAN has resulted in numerous features with various tradeoffs.
For example, to maintain the session, a technique called local acknowledgment (LACK) was developed. LACK is similar to a spoofing technique used in satellite networks for many years. LACK terminates the LLC2 session and locally maintains sequencing, retransmission, and flow control. However, LACK has drawbacks. It adds a measurable amount of latency that can affect high-traffic networks. In addition, not all WANs are low speed, so LACK is not necessary in all circumstances. To address these drawbacks, LACK can be disabled and LLC2 protocols can be supported across the WAN in a passthrough mode where the end stations once again resume the responsibilities of sequencing, retransmission, and flow control.
With either DLSw+ or FRAS running, LACK works in the following manner: explorers are passed through and supervisory frames are locally acknowledged, but synchronization of the session establishment does not occur until the remote station responds. I-frames are locally acknowledged. Flow control is handled locally.
It is important to note that even though data has been acknowledged, it has not been delivered. Acknowledgment means that data has been queued for delivery to a guaranteed delivery subsystem such as TCP/IP or LLC2 on the WAN. If the WAN session is lost, then all locally acknowledged LAN sessions that rely on that WAN session must disconnect because the data may have not been delivered to the remote location. There is no way to know for sure if data has been delivered so the only alternative is to disconnect the session.
In passthrough mode, all LLC frames pass through intermediate stations to the remote target stations. All the sequencing, retransmission, and flow control is handled by the end stations. If the intermediate WAN session is lost, then the end station LLC2 stack detects the failure (by timing out retransmissions) and implements recovery procedures. Passthrough modes are rare in Frame Relay environments because of the low speeds that are often present.
DLSw+ continuously converts from LLC2 on the LAN to SSP formats on the WAN. This conversion takes place regardless of the WAN encapsulation method. Thus, SSP is encapsulated in TCP/IP, IP (that is FST), direct HDLC, or LLC2.
DLSw+ has multiple encapsulation methods with varying levels of encapsulation overhead. However, in most cases the overhead is negligible and can be safely omitted as a design consideration. A discussion of each encapsulation method is beyond the scope of this guide. Please see DLSw+ Design and Implementation Guide for more information about encapsulation.
Frame Relay networks attracted attention because of their ability to more efficiently use shared backbone resources such as bandwidth. Frame Relay surpasses the traditional time-division multiplexing (TDM) functionality by allocating unused bandwidth to a connection that needs more bandwidth. This capability is the source of Frame Relay's success, but it also the source of many of its problems. To accommodate this ability, Frame Relay network designers have the additional task of engineering traffic in a process called provisioning. Now, instead of connections having dedicated bandwidth, a connection is assigned varying amounts of bandwidth, in a well-defined range, depending on the traffic conditions. Simply put, if traffic is light, connections get more bandwidth; if traffic is heavy, then connections get less bandwidth.
Two bits in the Frame Relay header are reserved to notify the directly connected end systems about the current traffic conditions. The backward explicit congestion notification (BECN) bit and the forward explicit congestion notification (FECN) bit send congestion indication information (see Figure 1-5). Though simplistic in principle, FECN and BECN mechanisms are a source of infinite confusion. The confusion may be because the terminology chosen is from the perspective of the network and not the perspective of the user. When congestion is detected anywhere along the path in a Frame Relay virtual circuit, the traffic heading in the same direction (forward traffic) has the FECN bit set on it. Traffic heading in the opposite direction (backward) has the BECN bit set on it. How the individual Frame Relay networks determine that congestion is present is specific to the switching equipment and the Frame Relay network designers.
Cisco routers respond to FECN by returning a test frame without any data, but with the BECN bit set. This relays the congestion condition to the source of the congestion. However, if the router detects a packet ready for transmission, it will set the BECN bit on it instead of using a test frame.
Upon receiving a BECN bit, Cisco routers respond in one of two ways. If the router is using DLSw+ Lite, then the LLC2 send window on the Frame Relay WAN is divided by two. Halving the send window causes the P/F bit in the LLC2 header to be set every window/2 frames. For example, if the window size is seven, then the P/F bit will be set every three frames instead of seven frames. Setting the P/F bit forces the remote link station in the Data Terminal Equipment (DTE) device, the remote receiving router, to acknowledge receipt of data more frequently, which ultimately slows down the sending router as it waits for acknowledgments. During periods of congestion this is important because it slows down the rate of transmission and also verifies receipt more frequently. Each time a BECN is received, the window size is halved until it reaches one. If eight frames are received without BECN, the window size is increased by one until the maximum window size is reached again.
The second way that a Cisco router responds to BECN requires Frame Relay traffic shaping. When traffic shaping is enabled and a BECN frame is received, the rate of transmission is multiplied by 75 percent or reduced by 25 percent. This occurs once every time interval (Tc) until a user-defined lower rate is reached (Tc = committed information rate [CIR] / access rate (AR)). If no BECN is received for eight consecutive intervals, the rate is increased by 1/8 until the maximum rate is reached (excessive or peak information rate [EIR or PIR]) or another BECN is detected. Thus, traffic rates fluctuate between and upper (EIR, PIR) and lower traffic rate (CIR or minimum information rate [MIR]) depending on the arrival rates of frames with BECN set on them.
BECN relies on the presence of backward (reverse direction) traffic to set the congestion notification bit. If there is no backward traffic, then no notifications can be sent. In addition, even with ample backward traffic, the timeliness of reverse traffic may not be adequate. With simplex traffic (for example, a video broadcast) the returning traffic on which to set the BECN bit will not be present often enough to provide congestion indications in a timely manner. To resolve this, an enhancement to the existing signaling protocol was made. This signaling enhancement, called consolidated link-layer management (CLLM), enables the Frame Relay network to more efficiently relay congestion notifications to the DTE (or router).
ForeSight is an advanced traffic management feature that reacts quickly to the slightest hint of congestion. On Frame Relay backbones, ForeSight detects congestion on a trunk, egress port, or virtual circuit and adjusts admission rates in the network at the point of ingress for a virtual circuit. Using CLLM, ForeSight can be extended to the router. Cisco calls this router feature Router ForeSight.
Cisco WAN switches send a CLLM congestion notification message every 100 ms on the reserved data-link connection identifier (DLCI) 1007. This notification rate permits ForeSight to efficiently update the router about congestion in the Frame Relay network. The switches send a single CLLM message to the Cisco router with a congestion state indication (a single bit for each DLCI) and cause of the congested state for each DLCI. If more DLCIs exist than can fit in a single CLLM message, then multiple messages are sent. For more information about CLLM, refer to ANSI T1.618 or ITU Q.922 Annex A.
Implicit congestion notification occurs when a frame is dropped. A silently discarded frame and a measurable increase in network delay are clear indications of network congestion to TCP/IP. Before viable explicit congestion notification schemes were implemented, TCP/IP existed on Frame Relay backbones because of the slow-start and back-off algorithms it implements. TCP/IP reacts to varying round trip times (RTT) and packet drops by adjusting the send window for a session. With slow-start algorithms, TCP/IP will eventually reach the rates (using the sliding window algorithm) that the Frame Relay virtual circuit can sustain. During periods of congestion, when a dropped packet is detected or RTT increases TCP reduces its transmission rate by reducing its send window. Through a series of computations involving RTT delays, sliding windows, and packet retransmission, TCP/IP will eventually reach a rate of transmission that approximates the CIR. Stateless nonwindowed protocols, such as UDP, and adverse network conditions, such as broadcast storms, do not fare well in a Frame Relay environment because there is no back-off algorithm.
|
|