THE BASIC GUIDE TO
|
| Table of Contents | Basic Guide Title Pages |
|
|
Chapter Five |
Previous chapters covered the what and how of frame relay. By focusing on applications, this chapter provides insight into the practical benefits of frame relay. We'll discuss frame relay applications that are widely deployed and others that are emerging.
Basic Trail: Go!
The basic trail will give you an overview of four popular and growing applications: LAN peer-to-peer networking over frame relay, SNA over frame relay, voice over frame relay (VoFR) and frame relay-to-ATM interworking.
Advanced Trail: Go!
On the advanced trail, we'll go into more detail about three of the applications covered on the basic trail. Specifically, you'll also read how RFC 1490 provides interoperability in SNA networks and how traffic is managed in SNA over frame relay applications. We'll also talk about how voice over frame relay works and the associated trade-offs. Finally, you'll find a discussion of the Interworking Function (IWF) and FUNI or ATM frame-based UNI.
View Points :
Figure 11: Traditional Solution for LAN or Client/Server Networking Go
Figure 12: Frame Relay Solution for LAN or Client/Server Networking Go
Figure 13: Parallel bank branch networks Go
Figure 14: Consolidated bank network Go
Figure 15: Integrated voice and data network Go
Figure 16: Frame/ATM Service Interworking Go
Figure 17: Frame/ ATM Network Interworking Go
Figure 18: Typical Multidrop SNA Network Go
Figure 19: SNA Network Migrated to Frame Relay Go
Figure 20: NCP direct RFC 1490 Network Go
Figure 21: FRAD RFC 1490 Network Go
Figure 22: Normal Speech Components Go
Figure 23: Frame/ATM Service Interworking (Translation) Go
Figure 24: Frame/ATM Network Interworking (Encapsulation) Go
Figure 25: ATM DXI and ATM FUNI Go
Table 4: Comparison of Frame Relay/ATM Interworking with FUNI and ATM DXI Go
Shortcut: Go!
The shortcut will give the highlights of the four applications discussed and the associated benefits.
Initially, frame relay gained acceptance as a means to provide end users with a solution for LAN-to-LAN connections and to meet other data connectivity requirements. Frame relay's compelling benefit is that it lowers the cost of ownership compared to competing technologies:
Application #1: Meshed LAN Peer to Peer Networking
In a traditional solution for LAN or client/server networking across a WAN, meshed network implementations can be costly. Since private line pricing is distance sensitive, the price of the network increases as geographic dispersion increases. Changes in network design normally require physical reconfigurations in addition to software changes, which increases the time to administer the changes. (See Figure 11.)
Figure 11: Traditional Solution for LAN or Client/Server Networking
Frame Relay for LAN or Client/Server
By moving to frame relay for LAN or client/server applications, additional VCs between locations can be provisioned for minimal incremental cost. Most public frame relay pricing is distance insensitive. Virtual connections are software configurable. Changes to VCs can be done relatively quickly. This makes frame relay ideal for meshed configurations. (See figure 12.)
Figure 12: Frame Relay Solution for LAN or Client/Server Networking
Application #2: SNA Over Frame Relay
Over the past few years there has been a migration of legacy traffic, such as BSC (binary synchronous communications) and SNA, from low speed leased lines onto frame relay services. Ratified standards from the Internet Engineering Task Force (IETF) and the Frame Relay Forum enable the encapsulation of multiple protocols, including SNA, over frame relay networks. Together, they provide a standard method of combining SNA and LAN traffic on a single frame relay link. This enables FRADs and routers, which provide network connectivity, to handle time-sensitive SNA and bursty LAN traffic simultaneously.
The integration of legacy and LAN-to-LAN traffic provides network administrators with a more efficient, flexible and cost-effective network as well as a number of other benefits:
Let's explore a few of these benefits. SNA installations have expanded their use of frame relay because it is a mature, proven and stable technology. Moreover, users can leverage existing capital equipment and maintain existing network management practices.
Frame relay can be integrated into SNA networks with little or no disruption. Users may migrate to frame relay without any changes to Front End Processor (FEP) hardware or software, SNA naming or network topologies.
Frame relay allows the familiar NetView tools and practices to be maintained, so there is no need to retool network operations or retrain operations staff. This allows users to migrate at their own pace to multi-vendor enterprise network management such as SNMP.
Because frame relay supports SNA's stated direction, end users have the comfort of adopting a migration strategy to distributed and peer-to-peer enterprise networks to advance and optimize their SNA network. Users benefit from improved response times and session availability with higher performance than the original multidrop network.
A typical frame relay SNA application will illustrate these benefits.
Frame Relay in a Banking Application
In a large bank with many branch locations, SNA and Binary Synchronous Communications (BSC) devices are co-located with LANs, resulting in parallel branch networks and high monthly WAN costs. (See Figure 13.)
Figure 13: Parallel SNA, BSC, Alarm, and LAN Branch networks
Consolidating traffic on frame relay customer premise equipment (CPE) eliminates parallel, serial protocol networks and LAN networks to each branch. The CPE provides an integration of devices typically found at the branch with emerging client/server applications.
How does it work? The frame relay CPE consolidates SNA/SDLC, BSC data and LAN data onto the frame relay-based WAN. This eliminates multiple single protocol leased lines connecting the branch to its host resources. It also exploits the advantages of the higher performance LAN internetwork to consolidate serial and LAN traffic, compared with low speed analog leased-line networks.
The result is better performance, greater reliability and lower costs. Because one frame relay access can be used to reach the same number of sites as multiple leased lines, the amount of networking equipment may be reduced. Monthly telecommunications charges are also reduced and the network is simplified.
Other benefits include efficient bandwidth utilization, predictable and consistent response times, enhanced session reliability and simplified network topologies and troubleshooting.
For example, a BSC-to-frame relay conversion can be performed by the frame relay CPE for BSC Automated Teller Machine locations that are supported by an SNA host at the data center. This leverages the bank's investment in capital equipment. (See Figure 14.)
Figure 14: Consolidated Bank Network
SNA Over Frame Relay Pays
Frame relay enables mission-critical SNA networks to improve performance and provide cost reductions. These savings are available because frame relay meets the response time, availability and management requirements of mission-critical applications.
If you're interested in the details of how frame relay can be used as a replacement for SDLC point-to-point networks and how RFC 1490 provides interoperability, take a look at the SNA section in the advanced trail.
Application #3: Voice Over Frame Relay (VoFR)
Today, non-traditional uses for frame relay are beginning to emerge. One new application, voice over frame relay (VoFR), offers telecommunication and network managers the opportunity to consolidate voice and voice-band data (e.g., fax and analog modems) with data services over the frame relay network.
In migrating leased line networks to frame relay, many network administrators found a cost-effective solution for their data needs. However, since many leased-line networks also carried voice, a solution was needed to address corporate voice requirements.
With the ratification of FRF.11, a standard was established for frame relay voice transport. Among other things, FRF.11 defines standards for how vendor equipment interoperates for the transport of voice across a carrier's public frame relay network.
Maximizing Frame Relay Networks
FRF.11 enables vendors to develop standards-based equipment and services that interoperate. It also enables network managers seeking to reduce communications costs and maximize their frame relay network to consider VoFR as an option to standard voice services.
In some cases, users may find they have excess bandwidth in their frame relay network that could efficiently support voice traffic. Other telecommunications managers may find that the incremental cost of additional frame relay bandwidth for voice traffic may be more cost-effective than standard voice services offered by local or long distance carriers.
VoFR can provide end users with a cost effective option for voice traffic transport needs between company locations. For instance, the network manager may integrate some voice channels and serial data over a frame relay connection between a branch office and corporate headquarters. By combining the voice and data traffic on a frame relay connection already in place, the user has the potential to obtain cost-effective intracompany calling and efficient use of the network bandwidth.
Figure 15: Integrated Voice and Data Network
Because it does not significantly increase network architecture, link speeds or CIR, the integration of voice, fax and data traffic over a single access link provides a viable option for network managers and adds to the growing list of new and non-traditional applications for frame relay.
For a discussion of how VoFR works, refer to the advanced trail in this chapter.
Users are finding that frame relay offers another significant advantage: the ability to interwork with other advanced services, such as ATM.
Application #4: Frame Relay-to-ATM Interworking
Frame Relay/ATM Interworking is a viable solution that provides users with low cost access to high speed networks. Ratified by both the ATM and Frame Relay Forums, the Frame Relay/ATM PVC Interworking Implementation Agreements (IAs) provide a standards-based solution for interworking between existing or new frame relay networks and ATM networks without any changes to end user or network devices.
Why do users want to interwork frame relay and ATM? While frame relay is well suited for many applications including LAN internetworking, SNA migration and remote access, other applications, such as broadcast video and server farm support, may be better suited for ATM networks.
Users are also interested in interworking frame relay and ATM networks to protect their capital investment in existing frame relay networks and to support planned migrations from frame relay to ATM.
Frame Relay/ATM SVC Interworking IAs are currently being developed.
Frame Relay-to-ATM Interworking Standards
There are two Frame Relay/ATM Interworking IAs for PVCs, each encompassing two different types of interworking. The first one, Frame Relay/ATM Network Interworking for PVCs (FRF.5) allows network administrators to scale the backbone beyond the 45 Mbps trunks supported by frame relay. In other words, it provides the standards for ATM to become a high speed backbone for frame relay PVC users. The second one, Frame Relay/ATM Service Interworking for PVCs (FRF.8) defines the standard for frame relay PVC and ATM PVC end users or systems to communicate seamlessly.
Frame Relay/ATM Network Interworking for PVCs can be thought of as encapsulation while Frame Relay/ATM Service Interworking for PVCs is translational between the two protocols. Let's take a closer look at each standard.
Frame Relay/ATM Network Interworking for PVCs
Frame Relay/ATM Network Interworking allows Frame Relay end-user or networking devices such as FRADs or routers to communicate with each other via an ATM network employed as the backbone.
For example, SNA terminal users connected to FRADs in branch offices communicate with frame relay-attached IBM 3745 Communications Controllers located in corporate headquarters locations using a high speed ATM network as the backbone.
The frame relay devices interact as if they are using frame relay for the entire connection without knowing that an ATM network is in the middle. An ATM backbone connecting multiple frame relay networks can provide scalability and high speed support for a large number of locations and end-user devices, without requiring changes to the devices themselves.
Figure 16: Frame Relay/ATM Network Interworking
Frame Relay/ATM Service Interworking for PVCs
Frame Relay/ATM Service Interworking enables communication between an ATM and frame relay network or end user devices. Frame Relay/ATM Service Interworking allows existing frame relay devices in the remote branch offices to communicate with end users at headquarters who are using ATM-based applications.
By enabling existing devices to access new ATM-based applications, Frame Relay/ATM Service Interworking protects the investment in existing equipment. This promotes the decoupling of client and server sides of the network, allowing each to use the resources that best meet bandwidth requirements and budget constraints.
Figure 17: Frame Relay/ATM Service Interworking
A Quick Look at IWF and FUNI
Before we leave frame relay to ATM interworking, there are two more topics we need to touch upon briefly. Then, if you're interested in more details on these topics, you can proceed to the advanced trail. The topics are Interworking Function (IWF) and Frame-based User-to-Network Interface (FUNI).
An important advantage of Frame Relay/ATM Interworking is that it provides solutions to support communications between frame relay and ATM environments without modifications to end user devices. However, successful support of end-to-end communications in a Frame Relay/ATM Interworking environment requires performing technical functions to compensate for the differences between frame relay and ATM. These functions are defined within the Frame Relay/ATM Service and Network Interworking IAs and are provided by the IWF generally located on the switch at the boundaries of the frame relay and ATM services. The advanced trail will discuss the responsibilities of the IWF and how it works.
FUNI was defined by the ATM Forum to provide frame-based access to ATM networks. It is an alternative to Frame Relay/ATM Service Interworking and it is most viable where the wide area infrastructure uses ATM. FUNI enables ATM quality of service levels for network throughput and delay to be maintained end-to-end, despite the fact that the access method is frame-based, rather than native or cell-based ATM.
Approved by the ATM Forum in 1995, the FUNI specification provides improved efficiency of access line bandwidth. FUNI enables users to transmit variable length (low overhead) frames rather than fixed length cells to the ATM network. The advanced trail will discuss how FUNI differs from ATM DXI (Data Exchange Interface) and the benefits of FUNI.
On the advanced trail, we'll go into more detail about three of the applications covered on the basic trail: SNA over frame relay and Voice over Frame Relay, and Frame Relay/ATM Interworking.
Frame Relay as an SDLC Point-to-Point Line Replacement
Traditional SNA networks are based on leased lines which connect multiple controllers to the Front End Processor (FEP). These are typically low-speed analog lines, which represent a single point of failure between user and host, as in Figure 18.
Figure 18: Typical multidrop SNA network
Multidrop leased-line networks are a familiar evil, subjecting network managers to the complexities of a multitude of leased lines. Despite advances in networking technology, many organizations continue to base their SNA mission-critical applications on multidrop private lines.
SNA networks using point to point non-switched lines can be migrated from SDLC to frame relay without any changes to the existing applications or hardware. Frequently, all that is needed is an upgrade to the communications software in the controllers.
Controllers that cannot be upgraded may be connected to a FRAD or router for frame relay connectivity. Frame relay uses the same hardware framing as SDLC, so all SDLC line interface couplers, modems and DSU/CSUs can be used with frame relay networks.
Another item to be considered when connecting controllers to a frame relay network is how the FRADs or routers connect to the remote and host sites on the SNA network. SNA has a form of maintenance communications called polling. An SNA device responsible for a sub-area network regularly polls each downstream controller for status, inquiring if it has data to send. At the remote site, each local controller responds.
In order to provide optimal networking conditions, frame relay access devices should provide local polling or a decoupled polling capability. A frame relay access device, such as a FRAD, should poll its downstream devices or respond on their behalf. This process, called spoofing, eliminates polls on the networking because only data is passed end-to-end. Extracting polls increases usable network bandwidth, directly impacting network performance, since at least 25 percent of SNA network traffic is polls.
Frame relay, as a virtual private line replacement, offers straightforward migration from the complexities of multidrop leased lines to a higher performance and more cost effective network.
As shown in Figure 19, migrating SNA networks to frame relay can occur without any change to FEP hardware or software. Users can realize significantly lower monthly WAN costs, which can pay for a frame relay migration within months.
Figure 19: SNA Network Migrated to Frame Relay
Upgrading to frame relay allows fully meshed topologies for redundancy and backup without managing a large number of dedicated lines. Adding and deleting virtual connections is done via network management and service subscription versus adding and deleting hardware. For high traffic volumes at a data center, frame relay supports access speeds up to 45 Mbps (e.g., T3/E3).
Frame relay supports "one-to-many" and "many-to-many" connections over a single line, where SDLC requires a multidrop line for a "one-to-many" configuration. SNA multipoint hardware configurations must be changed to point-to-point hardware configurations to use frame relay. The changes can be chosen to provide the best economic solution by combining the positioning of frame relay switches and frame relay terminal equipment. For example, frame relay switches may be used to provide the best use of point-to-point line tariffs, and FRADs may be used to provide frame relay to SDLC interworking, where SDLC multipoint lines are less expensive.
If users want additional cost savings, other migration paths are possible. For example, the FEP can be upgraded to allow direct connections to NCP (Network Control Program) from an RFC 1490-compatible FRAD, as shown in Figure 20. This eliminates a two box solution, which reduces hardware costs.
Figure 20: NCP-direct RFC 1490 Network
Alternatively, the FEP may be upgraded to a token ring connection from an SDLC line, and a FRAD provides connectivity to the host, as shown in Figure 21, eliminating hardware on the host.
Figure 21: FRAD RFC 1490 Network
With the additional bandwidth available from frame relay, overall performance including session availability and user response time is improved as users migrate from multidrop lines which are typically 4.8/9.6 Kbps to frame relay connections of 56/64 Kbps to T1/E1.
How RFC 1490 Provides Interoperability
Recognizing the ability of frame relay networks to carry multiple protocols, members of the Internet Engineering Task Force (IETF) developed a standardized method to encapsulate various protocols in frame relay. This multiprotocol encapsulation technique is called RFC 1490 after its IETF designation. ANSI and the Frame Relay Forum enhanced the multiprotocol encapsulation method to include support of the SNA protocols (FRF.3.1). FRF.3.1 was adopted and implemented by numerous vendors and is invaluable in multi-vendor environments. FRF.3.1 is used to carry SNA traffic across a frame relay network and may also be used to transport IP.
Protocol Encapsulation and Practical Implementation
Typically, SNA controllers, routers and FRADs encapsulate SNA as multiprotocol data as described in the Frame Relay Forum FRF.3.1 IA. SNA topologies supported across a frame relay network include:
FRF.3.1 shows how to encapsulate SNA Subarea, SNA/APPN with and without HPR within the RFC 1490 multiprotocol framework. Because data is transparent to the frame relay network, it allows multiple distinct protocols to be multiplexed across a single frame relay interface. Frame relay network access nodes are responsible for converting the user data into an appropriate RFC 1490 format for SNA and LAN traffic
There are other alternatives to RFC 1490 for transporting SNA over frame relay. One method uses routers to encapsulate SNA data within TCP/IP using a standard such as Data Link Switching (DLSw) for link layer transport. The transport method a user selects depends on the application involved and the type of network equipment used.
Traffic Management Considerations
The mission-critical nature of SNA applications requires prioritization and bandwidth allocation mechanisms to avoid poor response times and SNA session failures caused by large bursts of other data traffic. One solution is to assign a higher priority to SNA data than LAN IP/IPX data if both are multiplexed over the same virtual connection. Another alternative is to send the data streams over two separate virtual connections and use the frame relay CIR mechanism to allocate bandwidth dynamically to each virtual connection.
Bandwidth allocation by percentage of CIR is a feature supported by some FRADs and routers, and it may not require allocating separate PVCs. A smaller amount of bandwidth may be allocated (e.g., 20 percent) to the LAN traffic connection, giving the SNA traffic more frequent transmission opportunity. Further, it is recommended that both the frame relay service provider and the frame relay equipment support explicit congestion management indicators such as FECN/BECN and Discard Eligibility (DE). If these mechanisms are supported, SNA traffic flow is adjusted properly and packet discards are minimized. As with other applications carried over frame relay, congestion management plays an important role in supporting SNA applications.
Please visit the Frame Relay Forum's Web site (www.frforum.com) for a white paper on SNA over Frame Relay. This paper goes into more detail on the many options available for SNA over Frame Relay.
Voice over Frame Relay (VoFR)
Unlike most data which can tolerate delay, voice must be handled in near real time. This means that transmission and network delays must be kept small enough to remain imperceptible to the user. Until recently, packetized voice transmission was unattainable due to the voice bandwidth requirements and transmission delays associated with packet based networks.
Human speech is burdened with a tremendous amount of redundant information that is necessary for communications to occur in the natural environment, but which is not needed for a conversation to occur. Analysis of a representative voice sample shows that only 22 percent of a typical dialog contains essential speech components that must be transmitted for complete voice clarity (see Figure 22). The balance is made up of pauses, background noise, and repetitive patterns.
Figure 22: Normal speech components
Packetized voice is possible and low-bit rates are attained by analyzing and processing only the essential components of the voice sample, rather than attempting to digitize the entire voice sample with all its associated pauses and repetitive patterns. Current speech processing technology takes the voice digitizing process several steps further than conventional encoding methods.
VoFR Trade-offs
There are potential trade-offs when implementing VoFR. These include:
These trade-offs do not necessarily negate the value and promise of VoFR. Significant advances in digital signal processors and compression algorithms often provide voice at a level approaching toll quality, for a fraction of the cost of public service. VoFR vendors continue to add advanced capabilities in management and administration capabilities. In addition, future industry work will also seek to develop standards which define acceptable levels of quality and performance metrics for voice transport through carriers' frame relay networks.
Please visit the Frame Relay Forum's Web site (www.frforum.com) for a white paper on Voice over Frame Relay. This paper goes into more detail on how VoFR works and the mechanics of voice compression.
More on the IWF
As we discussed on the basic trail, support of end-to-end communications in a Frame Relay/ATM network requires performing technical functions to compensate for the differences between frame relay and ATM. These functions are provided by the IWF generally located on the switch at the boundaries of the frame relay and ATM services.
Primary responsibilities for services provided by the IWF include mapping various parameters or functions between frame relay and ATM networks. These include:
The IWF also supports traffic management by converting ATM and frame relay traffic conformance parameters, supporting PVC management interworking via status indicators and providing upper layer user protocol encapsulation.
Figure 23 illustrates the Interworking Function in a Frame Relay/ATM Service Interworking environment. To enable communications between a frame relay desktop device and the ATM based application, the IWF performs all tasks associated with mapping the frame relay User-to-Network Interface (UNI) Q.922 core-based message in the frame relay network to the ATM UNI adaptation layer in the ATM network. For more details, please refer to the Frame Relay and Frame-Based ATM white paper on the Frame Relay Forum web site (www.frforum.com).
Figure 23: Frame/ATM Service Interworking (Translation)
Frame Relay to ATM Network Interworking for PVCs may be thought of as encapsulating frame relay in ATM, since the ATM transport is transparent to the two frame relay users. The end user protocol suite remains intact. The IWF provides all mapping and encapsulation functions necessary to ensure that the service provided to the frame relay CPE is unchanged by the presence of an ATM transport. This is also sometimes referred to as frame relay transport over ATM. (See figure 24.)
Figure 24: Frame /ATM Network Interworking (Encapsulation)
How Does FUNI Work?
FUNI requires FUNI-compatible software in the user equipment and a complementary frame-based interface, as well as FUNI software in the switch to which user equipment connects. Within the switch interface, the frames are segmented into cells and sent into the network. Cells coming from the network are reassembled into frames and sent to the user. Thus, hardware costs of segmentation and reassembly are moved from the user equipment to the switch where it can be shared across a large number of users.
How Does FUNI Differ from ATM DXI?
Both the ATM DXI (Data Exchange Interface) and the ATM FUNI specifications translate frames of up to 2000 bytes into 53-byte ATM cells, but they differ as to where the translation takes place. The DXI standard requires a DXI-enhanced DSU to convert frames sent over an access line into cells and DXI software in the user equipment as well.
In contrast, the FUNI specification allows frames to be sent directly to the ATM switch where they are divided into cells, an approach which reduces processing and memory overhead in the remote server or workstation and makes more efficient use of the access line bandwidth. Figure 25 illustrates the two approaches.
Figure 25: ATM DXI and ATM FUNI
The major benefit of ATM FUNI is that it is "ATM ready." Although limited to VBR (variable bit rate) services, it uses the same schemes as cell-based ATM UNI in the following areas:
By contrast, frame relay requires Frame Relay/ATM Interworking functionality to achieve the same interoperability.
The current FUNI specifications address T1/E1 and Fractional T1/E1 (256 VCs per interface), whereas DXI supports full T1/E1, but not fractional T1/E1. Like frame relay and DXI, FUNI support for CPE routers consists of a software option.
Comparing Frame Relay/ATM Interworking with FUNI and ATM DXI
The following table helps to compare frame relay/ATM interworking with frame-based ATM.
|
Frame Relay ATM Service Interworking
|
FUNI
|
ATM DXI
|
|
|
Access Transport
|
Frame based
|
Frame based
|
Cells
|
|
Software Requirements
|
IWF in frame relay or cell relay switch
|
FUNI software in user device and ATM network switch
|
DXI software in user device and DSU
|
|
Hardware Requirements
|
None
|
None
|
May require enhanced DSU
|
When should you consider FUNI over Frame Relay-ATM service interworking? Clearly, one technology is not superior to the other. Rather, it amounts to selecting the solution which best addresses the network requirements, current topology and future network needs.
Since frame relay dominates the wide area architecture and remote site connectivity, Frame Relay/ATM Service Interworking is usually the most logical solution for most applications today. As the deployment of ATM approaches 50 percent of the wide area infrastructure, the case for deploying FUNI-based access becomes more compelling.
This chapter discussed four popular applications for frame relay: meshed LANs over frame relay, SNA over frame relay, voice over frame relay (VoFR) and Frame Relay/ATM Interworking.
END CHAPTER FIVE.
GO TO CHAPTER SIX
