51-10-33 SNA Over Frame Relay Previous screen Dick Thunen Payoff Frame relay is replacing expensive leased lines as organizations migrate to packet-based networks. This article examines how frame relay has become an integral part of IBM's overall wide-area internetworking strategy for integrating SNA and multiprotocol LANs. Introduction Today most telecommunications carriers provide frame relay services that allow the IBM Systems Network Architecture (SNA)user to reap a number of benefits, including:
á Investment protection in System Network Architecture devices.
á Lower line costs compared to dedicated links.
á Up to 40% increases in network utilization through frame relay's multiprotocol support.
á Sustained integrity and control of the SNA network with NetView and Simple Network Management Protocol (SNMP) management.
á Integration of SNA and multiprotocol LANs.
á High-performance access networking for Advanced Peer-to-Peer Networking(APPN) and a migration path to Asynchronous Transfer Mode backbones. Traditional IBM host networks connect users to mainframes via SNA or bisynchronous multidrop lines. These are usually low-speed analog lines that represent a single point-of-failure between user and host. Even though these networks subject network managers to the complexities of dealing with a multitude of leased lines, many organizations continue to maintain their IBM host networks because of the mission-critical applications they support. IBM Corp. introduced X.25 as a cost-effective alternative to private lines. Many network planners have chosen not to implement it, however, because of higher user- response times from network overhead delays caused by every node in the X.25 network performing error detection/correction, message sequencing, and flow control. Frame relay, however, performs these functions only at the network access points using an end-to-end protocol; thus Frame relay uses the network more efficiently. IBM has developed a set of SNA Frame relay products for packet-based, Wide Area Network (WANs). Frame relay is an integral element of the evolution of System Network Architecture networks into the future with full support for APPN and Asynchronous Transfer Mode. Frame Relay Technology: An Overview Frame relay is a relatively new technology offering virtual private-line replacement. As a network interface, it traces its origins to Integrated Services Digital Network. When integrated services digital network (ISDN) was being developed, two transport services were envisioned: circuit-mode services for voice and transparent data, and packet (i.e., X.25 and frame relay) mode for data. Frame relay has since evolved into a network Previous screen interface in its own right, independent of integrated services digital network (ISDN). It is now specified as a set of American National Standards Institute (ANSI) and International Telecommunications Union (ITU) standards. The User Perspective Although services are typically available with transmission rates from 64K bps to T1/E1 (1.53/2.05M bps), Frame relay is defined as an access interface up to T3 or 45M bps. By contrast, the typical Synchronous Data Link Control multidrop line is a 4.8K or 9.6K bps analog line. The transmission of a typical two-page text document on a Frame relay network takes 1/4 second at 64K bps and 1/100 second at 1.53M bps. Transmission of the same two-page text document on an SDLC multidrop line takes 3 1/3 seconds at 4.8K bps and 1 1/6 seconds at 9.6K bps. To the user, a Frame relay network appears simple and straightforward. Users connect directly to destinations on the far side of the network. Frame relay provides logically defined—links commonly called Data Link Connection Identifier (DLCIs), Permanent Virtual Circuit (permanent virtual circuits), or permanent logical links (PLLs)— for a permanent virtual connection. For example, user A is connected across the Frame relay network through separate permanent virtual circuits to both user B and user C. The permanent virtual circuits are multiplexed across user A's Frame relay interface. Frame relay networks guarantee bandwidth to each permanent virtual circuits, but allow unused bandwidth to be shared by all active users. The guaranteed bandwidth of a permanent virtual circuits is specified as the committed information rate (CIR) of the permanent virtual circuits. A user's traffic can have transmission data rates in excess of the Committed Information Rates, referred to as the burst rate of the permanent virtual circuits. User B appears to user A with Frame relay address data link connection identifiers 100, and user A appears to user B with data link connection identifiers 80. A permanent virtual circuits connects user A's Frame relay interface through the Frame relay network to user B's Frame relay interface. Each user's data link connection identifiers numbers have local significance only. User A has a second Permanent Virtual Circuit with its own data link connection identifiers number connecting to user C. In addition, each user has a Local Management Interface, typically on data link connection identifiers 0 (see Exhibit 1).
Frame Relay Permanent Virtual Circuit (PVC)
The Frame Relay Frame Each Frame relay access station is responsible for transforming the data into Frame relay packets for transport (i.e.,relay) over the network. Each frame contains the following elements:
á Flag. The flag indicates the start and end of a frame relay packet.
á Frame relay header. The header contains the destination of the user data packet and management information. á User data. The user data contains the data to be transported across the Frame relay Previous screen network. á Frame check sequence. The Frame Check Sequence allows the integrity of the data to be validated.
á The Frame relay network receives, transports, and delivers variable-length frames. The Frame relay network consists of a group of interconnected nodes (i.e., switches) that relay the data across the network on the appropriate permanent virtual circuits. A Frame relay switch uses only the data link connection identifiers information contained in the Frame relay header to forward the frame across the network to its destination (see Exhibit 2).
Frame Relay Network Showing PVC Connecting User A and User B The path through the network is transparent to the user. The data link connection identifiers does not include any description of how the connection transverses the network or the routing topology of the network. A frame relay network operates an Open Systems Interconnection (OSI) layer 2 router network. Each Frame Relay Access Node puts the Routing Information(destination Data Link Connection Identifier)in the data link layer (i.e., Frame relay header) of the frame. The Frame relay network uses only this information to relay the frame across the network. (See Exhibit 3.) In other words, the Frame relay network nodes look only at the Frame relay header and the FCS.
Layer 2 Router Network The Frame relay switch, or node, uses the following two-step review process to forward frames across the network:
á The integrity of the frame is checked using the frame check sequence; if an error is indicated, the frame is discarded.
á The destination data link connection identifiers address is validated, and if it is invalid, the frame is discarded. The data link connection identifiers destination address is contained in the Frame relay header of the frame.
á All frames that are not discarded as a result of the FCS or Data Link Connection Identifier checks are forwarded. The Frame relay node makes no attempt to correct the frame or to request a retransmission of the frame. This results in an efficient network, but requires that the user end-stations assume responsibility for error recovery, message sequencing, and flow control.
á Thus, Frame relay switches do not look at the user data packets, which makes the network transparent to all protocols operating at levels above OSI level 2. RFC 1490 Because Frame relay networks do not look at the contents of the user data, any format can be used to packetize the data, such as X.25or High-level Data Link Control. IBM uses Logical Link Control type 2 (LLC2) as its frame relay System Network Architecture data Previous screen format. The IBM format is based on ANSI T1.617a Annex F, which covers encapsulating protocol traffic in frame relay. This process has been approved by the Frame relay Forum and is included in its Multiprotocol Encapsulation Agreement. IBM's treatment of a Frame relay network is based on standards and promotes interoperability with third-party implementations. IBM uses the LLC2 frame format and protocol for transporting SNA across Token Ring and Ethernet LANs. For SNA data, the Regional Financial Center 1490 header designates that it is 802.2 (LLC2) data, whether it is SNA subarea, peripheral, or Advanced Peer-to-Peer Networking data, and the LLC2 destination and source addresses. This format, illustrated in Exhibit 4, is also used for NetBIOS data.
RFC 1490 Frame Relay Frame Format Users connected to the network using RFC 1490 Frame relay Data Terminal Equipment have a logical view of the Frame relay network as a virtual LAN. IBM's use of RFC 1490 for its Frame relay equipment provides a familiar metaphor to System Network Architecture users. Because the Frame relay network does not look at the contents of user data, it allows the multiplexing of multiple protocols across a single Frame relay interface. Frame relay network access nodes are responsible for converting the user data into the appropriate RFC 1490 format for SNA and LAN traffic. In summary, a frame relay WAN:
á Provides packet-mode technology.
á Does not utilize store-and-forward.
á Relies on intelligent endpoints and high-integrity lines.
á Results in low transit delay.
á Is transparent above layer 2.
á As a result, Frame relay provides a cost-effective alternative to dedicated-line networks. Frame Relay as a Replacement for SDLC Frame relay delivers enhanced services compared to alternative System Network Architecture WAN techniques such as SDLC Frame relay:
á Uses the same framing and Cyclic Redundancy Checking bits as SDLC. This means that all front-end processor (FEP) SDLC line interface couplers (LICs), modems, and DSUs/CSUs, can be used with frame relay.
á Usually allows for frames up to 2,106 bytes in a Frame relay network, but IBM's Network Control Program allows for the configuration of up to 8,250-byte frames for use on high-quality, private Frame relay networks. Large packets reduce network overhead and improve network performance. á Allows network access connections from 56/64K bps to T1/E1 speeds, whereas the Previous screen typical multidrop connection is 4.8/9.6K bps. User response times are directly improved by efficient network backbone connectivity.
á Is implemented in software (like SDLC), which means that no hardware changes in either the Front-End Processor or remote devices are required to move to Frame relay.
á Can be managed by NetView management by network control program (NCP) for both SDLC and Frame relay connections. Therefore, familiar network management tools and practices can be used on the Frame relay network.
á Adds multiple protocol transport. All protocols can be transported across the Frame relay network; SDLC supports only SNA traffic.
á Provides SNA guaranteed bandwidth through the PVC's committed information rate.
á Requires no host application changes to migrate from SDLC to Frame relay.
á Supports point-to-point connections, like SDLC. Frame relay also provides many-to- many connections; SDLC requires a multidrop line to provide one-to-many connections.
á Provides for transparent network routing. SDLC is a single physical path connection.
á Supports burst mode, which lets users exceed their Committed Information Rates of the link. SNA Frame Relay Networks IBM provides connections for frame relay networks on all its current networking products, including 3745 communication controller, 3172 interconnect controller, OS/2 RouteXpander/2, 3174 network server, AS/400,and the 6611 network processor. Users can evolve their current System Network Architecture networks from an SDLC multidrop backbone to a frame relay WAN. IBM supports all SNA topologies: Intermediate Network Node, Boundary Network Node, SNA Network Interconnect, and Advanced Peer-to-Peer Networking across a Frame relay network. IBM's Frame relay products are configured as Frame relay Data Terminal Equipment devices, except the Front-End Processor(3745 communication controller), which can also be configured as a Frame relay data communications equipment (DCE)device and can act as a Frame relay switch. Intermediate Network Node (INN) IBM's Network Control Program software provides an INN connection—PU4-to-PU4— between Front-End Processor over a Frame relay network. This support was first announced for network control program (NCP) Version 6, Release 1 (V6R1) in 1992. IBM supports mixed-media, multiple-link transmission groups that can include Frame relay, SDLC, and Token Ring links. Thus, Frame relay can be incorporated with other data link types in a transmission group to give users flexibility in network design. Because Frame relay is an Open Systems Interconnection level 2 routing protocol, it provides fast INN routing, which is an efficient means of interconnecting multiple FEP. Level 2 Frame relay eliminates SNA processing on intermediate FEP. Furthermore, as Previous screen each pair of FEP appears to be directly linked, the intermediate network configuration is transparent to SNA routing algorithms. SNA Network Interconnect (SNI) NCP Release 6, Version 1 also introduced SNA over Frame relay for interconnecting multiple SNA networks. Two traditional SNA networks can be connected using an System Network Interconnect link over Frame relay so the users of one SNA network can access the resources or applications of another across a Frame relay network. Boundary Network Node (BNN) NCP Version 7, Release 1 fully expands the role of the network control program (NCP) to that of providing System Network Architecture Boundary Network Node—PU4-to- PU2—connectivity between an network control program (NCP) and an SNA node (PU2/2.1). The FEP can establish an SNA/BNN connection across a frame relay network with users on a 3174 network processor or users connected through an IBM 6611 network server or RouteXpander/2. AS/400 IBM's AS/400 supports direct Frame relay connectivity to another AS/400, or through a Frame relay bridge to a 5494 remote controller or PC workstation. SNA nodes connected to an AS/400 across a frame relay network must be SNA Type 2.1 nodes, such as an IBM 5494 remote controller. APPN IBM's APPN Network Node products, 6611 IBM Network Processor, AS/400, and OS/2 Communication Manager (RouteXpander/2) can be configured to establish an APPN network across a Frame relay WAN. APPN end-node applications can thus take advantage of the combined Frame relay and APPN network. IBM Legacy Devices Many IBM networks include legacy devices that are incapable of supporting Frame relay network access, such as 3274 controllers, System 3X computers, and 5394 controllers. A Frame relay assembler/disassembler(FRAD) provides connection to a Frame relay network for a non-frame relay capable device. A FRAD translates the SNA controller's SDLC data stream into Frame relay frames for transport over the network. FRADs based on Regional Financial Center 1490 can interoperate across a Frame relay network with IBM's Frame relay products. Interoperability with IBM requires that the SDLC be converted to LLC2 for encapsulation in Frame relay. In addition to basic framing functions, a FRAD usually concentrates a number of low- or medium-speed SDLC lines into a single, high-speed Frame relay link. By combining data from multiple, low-speed controllers onto one or more high-speed lines, FRADs reduce overall network costs. Private Frame Relay Network Previous screen NCP Version 6, Release 2 (V6R2) adds Data Circuit-terminating Equipment support to the front-end processor. The FEP functions as a Frame relay switch (i.e., DCE) for Frame relay data terminal equipment (DTE) equipment, such as an OS/2 RouteXpander, so users can create private Frame relay networks based on the IBM FEP. Private Frame relay networks support both SNA and LAN protocols. In summary:
á All current IBM SNA products provide Frame relay network access.
á All SNA topologies are supported across a Frame relay network.
á FRADs can be used to provide high-performance connectivity for Legacy IBM SDLC and Binary Synchronous Communications devices. IBM Multiprotocol Support IBM's frame relay access products use the Regional Financial Center 1490 standard, which specifies the frame format and characteristics for multiplexing multiple protocols across a Frame relay network on a single, Frame relay link. Treatment of LAN protocols is similar to that described for System Network Architecture over-frame relay. The Regional Financial Center 1490 header for LAN protocols indicates whether the packet is being bridged or routed. A bridged frame header includes what media it is originating on—802.3, 802.4, 802.5, FDDI, or 802.6—whether it is being source routed or transparently bridged, and its destination medium access control (MAC) address. Some routed protocols have an assigned Direct network layer Protocol Identifier, or NLPID, such as IP. For these protocols the NLPID is used to identify the frame. Otherwise, the Subnetwork Access Protocol (SNAP) header for the frame is used to identify frame contents. RFC 1490 specifies the transport of both bridged and routed LAN protocols across a common Frame relay interface and provides a standard format for the Frame relay packets. RFC 1490 specifies for bridged data the protocol being used—source route or transparent—and thus facilitates multivendor networking based on industry standard implementations. For routed data, however, there is currently no means of specifying the routing protocol being used for a given LAN protocol, so interoperability of routed protocols is more complicated. All of IBM's Frame relay products provide for multiprotocol support over Frame relay. This support is available over public and private Frame relay networks and includes both the bridging and routing of LAN protocols. The IBM 6611 also allows SNA/SDLC traffic to be transported across a Frame relay WAN. Network Management With the addition of frame relay as a packet-mode WAN supported by IBM's Network Control Program software, IBM incorporates support for Frame relay WAN in NetView network management software, including NPM and NTune and NetView/6000, its Simple Network Management Protocol manager. IBM provides a complete picture of the System Network Architecture and Frame relay internetwork including both SNA and non-SNA traffic and Data Terminal Equipment devices. Exhibit 5 shows the System Network Architecture network management topology. Previous screen SNA Network Management Topology
NetView Management Services Although simple network management protocol and other open network management standards continue to evolve, NetView remains the only way to provide comprehensive network management, control, and diagnosis of an System Network Architecture network. All SNA network nodes are inherently commandable from NetView and report all network management-related activities directly to NetView for processing by one of its function-specific applications. IBM's NetView support extends NetView management of the SNA network across the Frame relay network to the end user's controller. This support allows complete SNA network visibility and control with no remote-line and physical unit black holes, compatibility with existing NetView tools and applications, and virtually no operator retraining. Virtual Telecommunications Access Method (VTAM) Network Control Program(NCP) The Virtual Telecommunications Access Method Dynamic Reconfiguration (DR) facility supports the addition of network control program (NCP) Frame relay Data Link Connection Identifier. Permanent Virtual Circuit can be created or deleted without interrupting the Frame relay network or regenerating network control program (NCP). Alternative Routing NCP provides alternative automatic routing by a private Frame relay network if a primary (i.e., public) frame relay network becomes unavailable. Local Management Interface (LMI) A reserved link address (local data link connection identifiers) is used for communication between the FRAD and the Frame relay network. The management interfaces are defined by American National Standards Institute T1.617-1991 Annex D and ITT Q.933 Annex A for data link connection identifiers 0. Users are able to specify either the ANSI or ITT Local Management Interface implementation as part of the configuration. This data link connection identifiers is used for communicating network resources (i.e., the list of valid data link connection identifiers),determining the link status of each data link connection identifiers, and determining network status. The local management interface data link connection identifiers cannot be used for data traffic. A status-inquiry message is used to query the status of the network. The status message is either a keep-alive message or a full-network status report. The status update message reports an unsolicited status change in a network component. Frame Relay Network Congestion The Frame relay network provides notification of network congestion to end-user devices. Upon encountering congestion a Frame relay switch provides forward notification of network congestion along the data route by setting the Forward Explicit Congestion Previous screen Notification bit in the Frame relay header, as shown in Exhibit 6.
Frame Relay Header The network also notifies the sending node of congestion along the pvc by setting the Backward Explicit Congestion Notification bit of packets going to the sender along the permanent virtual circuits. The bit is changed from 0 to 1 to indicate the presence of congestion. Network congestion is determined by a switch using the switch's queue length or buffer utilization. (See Exhibit 7.)
Congestion Notification It is the function of the Frame Relay Access Node, or data terminal equipment (DTE) device, to respond to the forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN) bits. IBM's Frame relay devices respond by controlling the transmit window size of devices transmitting on the congested Data Link Connection Identifier. When a Frame relay data terminal equipment (DTE) receives notification of network congestion, it reduces its transmit window to 1. Once a network has indicated that it is returning to a normal state, the transmit windows are increased a frame at a time until they return to their normal transmit windows. Consolidate Link Layer Message (CLLM) If there are no frames returning to the sender, the end node can determine the presence of congestion over a data link connection identifiers through the CLLM information on the next query. The network is otherwise prohibited from notifying the sender of congestion on the data link connection identifiers. Discard Eligibility Bit Frame relay access nodes can mark frames for Discard Eligibility by the network as a means of reducing congestion during moderate traffic congestion periods. When the discard eligibility bit in a frame is set to 1, the user has indicated that the frame can be discarded if it encounters network congestion. The network sets the discard eligibility bit to 1 on data that follows on a physical link in excess of the Committed Information Rates. Thus, the network can be divided into the following three zones:
á Guaranteed transmission. The data flow is less than the CIR
á Transmit if possible.The data flow is above the CIR but less than the maximum rate.
á Discard excess frames. The data flow is above the maximum rate. The Frame relay network does not notify a user of frames being discarded. It is the responsibility of the FRADs to monitor the integrity of the data flow. SNMP Management Previous screen Proliferation of LAN internetworks often leads to a separate management organization seeking a common management platform for multivendor equipment. Often the solution is simple network management protocol. Most of IBM's Frame relay products can be configured with an Simple Network Management Protocol agent for management by IBM's NetView/6000 simple network management protocol Manager. Support of concurrent simple network management protocol and NetView enables each functional operations group, System Network Architecture and LAN internetwork, to execute their respective network management and control responsibilities through their management platform of choice. Frame Relay Compared with Router Networks IBM's products transmit LAN, System Network Architecture, and Advanced Peer-to-Peer Networking traffic across a frame relay WAN. The following section compares IBM's treatment of a Frame relay WAN and the router approach. The major issues include:
á Backbone. A Frame relay network is compared with a meshed-router backbone network.
á WAN protocol. IP encapsulation is compared with native-protocol Frame relay transport.
á SNA support. Support for all SNA interconnects is compared with data link switching (DLSw).
á Network management. Native NetView and Simple Network Management Protocol are compared with Simple Network Management Protocol. Backbone The typical router backbone is a mesh of point-to-point links. In these networks, the router backbone is the network. The router is responsible for routing between end-user clients and application servers. Thus, routers are responsible for the definition and maintenance of network topology and the appropriate routing path for applications. Router networks may be referred to as administratively rich. In a Frame relay backbone, by contrast, the network services are inherent in the Frame relay service. Each Frame relay access device provides application-transparent communication directly with its corresponding node across the network. This simplifies the configuration and administration of Frame relay compared to a router-based network. WAN Protocol The router solution to this issue is to encapsulate all traffic in IP packets for transmission over the Frame relay (or other) network in conjunction with a proprietary routing protocol. Thus, the router solution is based on adding IP framing overhead to all data prior to adding Frame relay framing for transmission over the network. Because most router protocols are proprietary and noninteroperable, a single vendor's product must reside on both sides of the network. SNA Support Previous screen The router solution is to use data link switching (DLSw) to terminate SDLC and LLC2 traffic in the router and encapsulate the SNA data in IP using the DLSw routing protocol over the WAN. This provides a single backbone protocol for System Network Architecture and non-SNA traffic over the WAN. Once the SNA data is encapsulated in IP, the WAN treats it as any other IP traffic. The router solution requires a second DLSw- compatible router on the destination side of the Frame relay network to remove the SNA data from the IP packet. However, DLSw only covers SNA/BNN PU2 data on SDLC lines and Token Ring LANs and NetBIOS traffic. IBM uses Regional Financial Center 1490for the transmission of SNA data over a Frame relay WAN network. RFC 1490 provides for the transport of SNA/BNN PU 2 and type 2.1, but also SNA Intermediate Network, Advanced Peer-to-Peer Networking, and SNA Network Interconnect traffic across a Frame relay network. Therefore, RFC 1490 covers all SNA traffic without encapsulation in IP, and DLSw covers only SNA/BNN PU2 traffic and adds the IP overhead. Network Management SNMP is the principal network management tool used with routers, whereas NetView is the network management tool of choice for SNA networks. The simple network management protocol management stations are not usually located in corporate data centers, which necessitates a separate set of Data Link Connection Identifier for simple network management protocol management to each remote location. Such a scheme creates a redundant tier of network overhead that reduces bandwidth availability for data, impedes SNA session responsiveness and reliability, obstructs NetView visibility, and complicates network design and problem solving. This results in poor SNA network performance in terms of efficiency and cost. When SNA is internetworked using routers that do not provide NetView support, a “black hole” is created in the network, preventing the NetView operator from viewing, managing, or monitoring the Frame relay Data Terminal Equipment devices. In particular, routers usually do not support SDLC LL2, LPDA-2, or NPM statistic collection. IBM provides an integral NetView connection in all its Frame relay products. NetView connections share the same Permanent Virtual Circuit as SNA data, thereby eliminating the need for a separate management network for communication with NetView and its component applications. Conclusion Frame relay—multiplexing multiple protocols over a common link—is an efficient solution for unifying LAN and System Network Architecture networks. frame relay is the WAN of choice for organizations moving to Advanced Peer-to-Peer Networking. The wide-scale deployment of APPN networks will soon be served by IBM's High- Performance Routing technology to deliver connectionless routing, and Frame relay will be supported by IBM's initial implementations of High Performance Routing (HPR). Exhibit 8 illustrates Frame relay as the unifying network for LAN and SNA. Frame Relay as the Unifying Networks for LAN and SNA Networks Previous screen Current Frame relay network specifications and service-provider implementations are designed for Permanent Virtual Circuit. permanent virtual circuits provide a direct replacement for leased-line SNA connections, but SNA networks often include switched, dial-up SDLC connections for casual System Network Architecture host access. This capability is being added to Frame relay. A number of vendors have initiated standardization of Switched Virtual Circuit (SVCs). Frame relay is also being positioned as the access network for Asynchronous Transfer Mode. An Regional Financial Center that specifies a Frame relay interface to asynchronous transfer mode (ATM) networks is currently being worked through the standards process. This interface, referred to as Data eXchange Interface, covers Asynchronous Transfer Mode adaptation layer 1 (AAL 1). Frame relay provides users with short-term payback and long-term preparedness— immediate economic benefits and a migration path to future, High Performance Routing (HPR) and networking. Author Biographies Dick Thunen Dick Thunen is a marketing representative of Sync Research, Inc. of Irvine CA. He can be reached at (714) 460-4430. Previous screen Previous screen Previous screen Previous screen Previous screen Previous screen Previous screen Previous screen