Wide Area Networking with Frame Relay and NetWare MultiProtocol Router
Articles and Tips: article
Product Marketing Engineer
Network Infrastructure Division
01 Feb 1995
Due to the increasing demand for data processing in geographically dispersed organizations, wide area networking solutions have proliferated. New WAN protocols and communication methods are needed to keep up with these demands. Frame relay provides a common transport for multiple protocols, and is well suited for network traffic over WANs. This Application Note introduces the frame relay architecture, tracing its origins and development and comparing it with other WAN protocols. It gives network designers and administrators an in-depth look at the inner workings of the protocol and provides a checklist for implementing WAN connections with frame relay. It also describes the features of Novell's NetWare MultiProtocol Router software relating to frame relay connections.
- Introduction
- Comparing WAN Protocols
- Frame Relay In-Depth
- Frame Relay Services
- NetWare MultiProtocol Router
- Conclusion
Introduction
Frame relay is one of several protocols currently contending for widespread acceptance as a wide area networking (WAN) standard. In its simplest form, frame relay works within the two lowest layers of the OSI (Open Systems Interconnection) Reference Model, developed by the ISO (International Organization for Standardization). It is used between intelligent end-points and implemented over high-quality transmission facilities.
Frame relay provides the following functions:
Interconnection for devices requiring high throughput in short durations, such as LAN routers
Low transit delay networking interface
High-speed, variable-length packet switching
"Mesh" networking design, which provides a cost-effective alternative to leased lines
Origins
Over the last decade, packet switching technology has been dominated by X.25, one of the oldest and most widely used communication transports in the world. Many sources describe frame relay as the next generation of packet switching. Frame relay derives its origins from the ISDN (Integrated Services Digital Network) specifications developed in the 1980s. The first contributions to the standards communities on the frame relay protocol appeared in late 1984. However, it was not until 1988 that the American National Standards Institute (ANSI) Accredited Technical Committee T1 approved the initial frame relay specification. Frame relay services started to become generally available in late 1993.
With the rapid evolution of reliable data communications equipment and transmission facilities, frame relay has become more and more popular as the next step in packet technology transport.
Meeting Today's Computing Demands
Today, competitive business markets continue to shape the nature of how we communicate. With the continuing proliferation of LANs, the requirements for data networking are constantly increasing. As the computing environment evolves from a LAN-centric model to a WAN-centric model, corporations are redistributing network processing and utilizing the increased intelligence on network end-points. This is an ideal platform for integrating frame relay.
Due to the overwhelming increase in frame relay's popularity over the past few years, major telecommunications carriers have been forced to ramp up their frame relay services. For example, Sprint recently announced plans for a nationwide overhaul of its data networks to meet these demands. The rapid spread of frame relay is mostly due to the significant cost savings - up to 40 percent compared to private leased lines. (Source: "Sprint grows network to cope with WAN demand," InfoWorld, Sept 26, 1994, v16 n39, p. 50.)
Strengths of Frame Relay
The three main areas in which frame relay demonstrates significant advantages over other WAN protocols are:
Reduced internetworking costs (in both hardware and carrier tariffs)
Increased performance with reduced network complexity
Increased interoperability via international standards
Reduced Internetworking Costs. With frame relay, equipment costs are lowered because fewer port connections are required to access other networks. Frame relay provides multiple logical connections through a single physical connection, thus reducing your access costs. This is illustrated later in the section which compares frame relay with Point to Point Protocol (PPP).
Software-based routers, such as Novell's MultiProtocol Router, enable PCS (486/33 minimum) to work as fully functional routers. Software-based routers provide support for transmitting data over a variety of wide-area links, including leased lines, analog lines, Frame Relay, Integrated Services Digital Network (ISDN), and Switched Multimegabit Data Service (SMDS). By using a software-based router as a frame relay connection device, you can save money over dedicated routers while consolidating routing and server functions into a single system.
Within the last year, major telecommunications carriers have simplified the service and reduced pricing for frame relay services. This makes frame relay easier tobuy and implement and more cost effective than may other WAN services. Later, in the section entitled "Frame Relay Services," we'll give a detailed description of the most common options to choose from when customizing your frame relay service.
Increased Performance with Reduced Network Complexity. Frame relay reduces the complexity of the physical network without disrupting higher-level network functions. Frame Relay functions using only the bottom two layers of the OSI model, as compared to X.25 which includes the Network layer (see Figure 1). By reducing the amount of processing required, and by efficiently using high-speed digital transmission lines, frame relay can improve performance and response times for most applications.
Figure 1: Frame relay uses only the bottom two layers of the OSI model.
Increased Interoperability via International Standards Frame relay's simplified link layer protocol can be implemented over existing technology. Access devices often require only software changes or simple hardware modifications to support the interface standard. Existing packet switching equipment and T1/E1 multiplexers often can be upgraded to support frame relay over existing backbone networks.
Frame relay is an accepted interface standard that vendors and service providers are adhering to and implementing. There is exceptionally good interoperability between the various standards. Further, most equipment vendors and service providers have pledged their support for frame relay development and standards. The simplicity of the frame relay protocol accommodates quick and easy interoperability testing procedures between devices from different vendors. This interoperability testing is currently in progress among vendors, as are certification processes for carriers providing frame relay services.
Frame Relay Issues
Although frame relay has many advantages, there are two areas within frame relay that can promote potential problems: congestion control and frame discard.
Congestion Control. As with most WAN services, without careful design, a frame relay network can quickly become congested. The CIR (Committed Information Rate, discussed in more detail in the section entitled "Frame Relay Services") is only a guideline for the access device to follow. The possibilities are still there for an access device to burst beyond the CIR. When frames are being sent beyond the agreed CIR, there is an eligibility for discarding frames due to congestion.
Frame Discard. When a problem is experienced with a single frame, frame relay simply ignores the problem and discards the frame. If a large number of problems occur, a significant number of frames are discarded and the end user system must recover from the situation. These errors cause retransmissions, thus placing additional bandwidth demands on the frame relay network.
ANSI applied specifications for Congestion Notification Mechanisms to allow frame relay devices to indicate the existence of congestion in the network. In the frame relay packet header, two bits are used for explicit congestion notification:
Forward explicit congestion notification (FECN)
Backward explicit congestion notification (BECN)
When a node on the network approaches a congestion condition caused by a temporary peak in traffic, the node detects the onset of congestion and signals all the downstream nodes. All attached devices learn that congestion has occurred and minimize until the network traffic subsides, as shown in Figure 2.
Figure 2: The FECN and BECN bits can be used for congestion control in a frame relay network.
In the case of traffic going in one direction (that is, from Florida to California), frame relay standards prohibit the network from generating any frames with the DLCI (Data Link Control Identifier) of a particular virtual circuit causing the traffic. Therefore, the congestion notification must wait for traffic in the reverse direction.
Note: ANSI has defined another mechanism called Consolidated Link Layer Management (CLLM), which reserves DLCI number 1023 on a frame relay interface for sending messages back to the source.
The fact that the burden rests on the protocols to take advantage of using the FECN and BECN bits is one of the attractive features of frame relay. However, the frame relay standards simply provide mechanisms for flow control techniques; they do not guarantee that they are implemented. These are vendor-specific issues that can result in product performance differences, but they do not usually interfere with basic frame relay interoperabilities. IPX/SPX, TCP/IP, AppleTalk and Token-Ring SRB (Source Route Bridging) the four main protocols used with Novell networks, have no design in the OSI model to address notification from the FECN and BECN bits.
Frame relay's congestion control mechanism works well in large, public switch environments because congestion can be controlled between the frame relay switches. Until CPE (Customer Premises Equipment) is designed to handle congestion notification between the CPE and the frame relay switch, this is where network traffic can generate traffic beyond manageability.
Comparing WAN Protocols
Since LANs have grown from connecting an assortment of intelligent PCS, they bring with them PC applications with their quick response times and ability to handle large quantities of data. These applications typically assume that LAN bandwidth - typically running at 4, 10, or 16 Mbps - is available. As a result, the applications are typically designed to transfer data at those rates. When designing a WAN to support these PC applications, the question often arises as to which of the available WAN protocols will best accommodate the bandwidth requirements.
In the continuing effort to meet user demand for similar response time over WANs, frame relay appears to be an excellent alternative to leased lines and X.25. The following sections compare frame relay with other popular WAN protocols and list their advantages and disadvantages with respect to frame relay.
X.25 Protocol
X.25 is a connection-oriented protocol (or datagram over the WAN) designed for use in either of two types of circuits: switched or permanent.
A Switched Virtual Circuit (SVC) is a circuit connection that you would expect with an on-demand type of service. The SVC is like a telephone call where one site requests a temporary connection to another site.
A Permanent Virtual Circuit (PVC) is much like connecting a hotline between two sites. The hotline stays operational and can be used at anytime. These circuit types still require permanent access to the telephone company, which entails a monthly access charge.
Comparing frame relay with X.25, both protocols are based upon the principle of packet switching technology. In the engineering for each protocol, a focus was made in the area of data-type applications, not so much with voice and real-time video.
Advantages. X.25 is a protocol designed for data transfer over public telephone lines. It was first developed in the 1960s to support host-to-host data transfer over noisy lines. To provide redress for the problems with noisy transmission, X.25 performs extensive error checking and error recovery. In a switching network, X.25 checks packets from each switch. Packets are only forwarded when a positive acknowledgment is received. Thus the X.25 protocol achieves high reliability at the expense of low data transfer speed.
Disadvantages. The disadvantages of X.25 become apparent when we look at how it differs from frame relay. As we saw in Figure 1, X.25 uses the lower three layers of the OSI mode during data transmission. The area of error checking shows the main differences with the two protocols. As mentioned earlier, X.25 provides error correction and retransmission functions. The link layer peer protocol specified in X.25 is called LAP-B (Link Access Procedure-Balanced). The LAP-B provides link management, error control, flow control and failure recovery. These operations take place in the Data Link and Network layers. A high level of guarantee is given to the originator that the data is received with no errors and in the correct sequence.
Unlike X.25, frame relay does not use the third (Network) layer of the OSI model. The processing diagram in Figure 3 demonstrates the differences between frame relay and X.25. This significant reduction in the processing requirement of the frame relay protocol results in an improvement in the overall switch performance. The advent of highly reliable transmission links paved the way for frame relay to solve the problem of very high speed data networking across packet switching networks.
Figure 3: Frame relay requires less processing overhead because it operates only in the Physical and Data Link layers.
Frame relay view errors in very simple terms: if there's a problem, discard the packet. Frame relay relies on the Network-layer protocols to perform retransmission and error recovery. As a result, there is less processing required within a frame relay provider's network nodes and, consequently, less delay when transmitting across a network. This allows higher traffic volumes and greater channel speeds without necessarily increasing equipment cost or complexity. Frame relay allows data traffic to move rapidly within network nodes in a data "highway," passing telephone company switches with a minimum of processing. It can thus achieve speeds of up to 2.048 Mbps.
Point-to-Point Protocol (PPP)
PPP is a data transport protocol derived from the SLIP (Serial Line Interface Protocol). PPP is a data-link layer protocol that encapsulates IP internetwork data, IPX/SPX, TCP/IP, AppleTalk and Token-Ring. It supersedes the older asynchronous SLIP, which was limited to speeds of up to 56 kbps and protocol support for only TCP/IP only.
PPP works similarly to frame relay in the area of packet discards. It relies on clean, reliable data transmission mediums and discards packets received in error, letting the higher-level protocols sort out the retransmission.
Advantages. PPP can support configuration and management of links between router software through a serial interface in both synchronous and asynchronous mode. Definitions are made in the protocol for automatic establishment and configuration of serial links in both router-based and bridge-based networks. PPP provides information exchange between routers having proprietary addressing schemes.
PPP is an excellent solution for designing a router-based network with a small number of routers using higher level protocols to account for discarded data. PPP can be configured so that it does not tie up the entire transport circuit. It can be shared with other serial line protocols.
Disadvantages. Whereas PPP works well in a small, router-based network environment, the disadvantages come into play as the number of networks increases. In a lease line environment, a physical connection is required at each site. This adds to the requirements for router ports, modems, and private lines, along with other miscellaneous costly items.
When compared with the equivalent service provided by dedicated leased PPP lines, frame relay services will save you money in the following areas:
Logical Connections
Port Connections
Equipment Cost
Tariff Structure
Figure 4 gives an excellent example for understanding how the savings are made. Figure 4 compares the private line with the frame relay "mesh" network. The same five sites are inter-connected with 10 interexchange carrier (IXC) virtual circuits.
In the private line scenario, each site must have a dedicated line to every site in the network to create a mesh network. The private line network therefore consists of 20 serial ports and 20 local exchange carrier (LEC) loops.
In the frame relay network, only five serial ports and five local loops are required. In general, frame relay networks reduce the number of ports and local loops because accessing frame relay networks requires only a single point of entrance.
Figure 4: Due to its "mesh" design, a frame relay network requires fewer ports and local loops than a private line network. design, a frame relay network requires fewer ports and local loops
Frame Relay In-Depth
This section goes into more depth on the internal workings of the frame relay protocol. We'll define some terms that are important to understand, examine the format of a frame relay packet, look at the operation of the protocol, and briefly discuss management processes.
How Frame Relay Works
When looking into frame relay, most people raise the following question: How can one router with a single direct link into a frame relay network establish connection with multiple routers or CPEs? To answer this question, let's first define some terms. The discussion following these definitions will give you a better understanding of how PVCs, DLCIs and LMI function together to enable and manage frame relay links to other routers.
PVC Permanent Virtual Circuits are one example of connection-oriented service. Most protocols operate in connection-oriented mode. This makes more efficient use of the circuit by bringing down the link when not in use.
DLCI The Data Link Connection Identifier distinguishes separate virtual circuits across each access connection. It allows the frame (packet) to be routed to the correct destination within a frame relay network. This is similar to X.25 implementation of the LAP-Dcore protocol functions.
LMI The Local Management Interface features handle information exchanges between the network and the user-attached devices, providing standards for such elements such as support of automatic reconfigure of devices and fault detection. LMI features also enhance service by providing the user with status and configuration information on the PVCs active at that time. The physical layer on the OSI model is where this process takes place. Standards are only defined for permanent virtual circuits between data terminal equipment with frame relay networking equipment.
Frame relay was initially defined as a permanent, connection-oriented protocol. PVCs are set up through your telecommuni-cations company (telco) or network administrator. With earlier implementations of PVC, once the connection is established, it can't be cleared at any time. The network is permanently available until the network itself shuts down.
After your PVC is configured, you simply configure your LAN router with the proper DLCI to use for communication. DLCI numbers are provided by your telco or network administrator and represent the frame relay CPE/LAN addresses. The path is available immediately and communication between the routers can commence.
The area within the frame relay packet structure that contains the necessary information to communicate with other routers is sometimes referred as the Address field. The next section covers the frame relay packet structure and provides a breakdown of the Address field.
Frame Relay Packet Format
Like other bit-synchronous protocols, frame relay uses a frame or packet structure as the basis for transmission. The frame format used by frame relay is based on Link Access Protocol for ISDN-D channels, which defines the functions for the OSI Data-link layer. (The frame structure for frame relay is derived from the high-level data link control or HDLC procedure.)
Frame relay was originally defined by the CCITT as a network service within the framework of ISDN. Because hardware already provided support of ISDN, using the derivative of the LAP-D protocol cuts down on protocol implementation and the need to change hardware.
Figure 5: Structure of a frame relay packet.
Explanation of Packet. The fields in the frame relay packet are as follows:
The Flag fields delimit where the data frame begins and ends.
The Frame Relay Header contains the DLCI, the FECN and BECN bits, and other information (see the "Operation" section for a description of how the header is used).
The Information field holds the actual data being transmitted (the "payload"). It can hold from 262 to 1600 or more octets (equivalent to a byte).
The FCS (Frame Check Sequence) is an error checking field. Frame relay uses a Cyclic Redundancy Check (CRC). If Frame Relay detects an error here, it drops the frame. The Network-layer protocol must request a retransmission.
The DLCI fields in the frame relay address header contain the Data Link Connection Identifier, described earlier. These fields can store two octets containing a 10-bit DLCI.
The EA (Extended Address) bits make it possible to extend the header field to support DLCI addresses of more than 10 bits.
The FECN (Forward Explicit Congestion Notification) bit may be used to notify the user that congestion was experienced in the direction of the frame carrying the FECN indication.
The BECN (Backward Explicit Congestion Notification) bit may be used to notify the user that congestion was experienced in the opposite direction of the frame carrying the FECN indication.
The C/R field in the header contains Command/Response information. These bits relate to congestion information stored if the network is experiencing congestion because several data sources are contending for the same bandwidth.
The DE (Discard Eligibility) bit allows the network to determine which frames may be discarded under congestion situations.
Operation
Multiple protocols can be multiplexed over a DLCI, which identifies the preestablished path (the PVC) through the frame relay network to the correct destination. The DLCI in the frame relay header is used to identify the logical channel between the user and the network. This allows data coming into a frame relay network node to be sent across the interface by specifying the DLCI rather than a destination address. Rather than requiring a separate physical facility for each conversation (or connection), the DLCI denotes which conversation "owns" that particular information.
In the example shown in Figure 6, Server 1 is sending data to Server 2 on a local DLCI (122) even though Server 2 is using DLCI 176 to communicate back to Server 1. DLCIs have only a local significance, so it is the responsibility of the network to map the access DLCIs to the destination. In Figure 6, Server 3 communicates with Server 1 through yet another DLCI, again with local significance. The local significance of the DLCIs also enables DLCIs to be reused at different interfaces.
Figure 6: Example of how DLCI addresses are used in sending packets across a frame relay network.
Frame relay places the responsibility of ensuring data delivery on the end-point devices that are operating with multi-level protocols. End-points can be devices such as networks, workstations, and hosts. To ensure that all packets have been received, the Transport layer (layer 4) of the OSI model places a sequence number on the frames that are sent. As with X.25, this functionality is performed in the Data-link layer.
Special management frames, with a unique DLCI address, can be passed between the network and the access device. These frames monitor the status of the link and indicate whether the link is active or inactive. They can also pass information regarding status of the PVC and DLCI changes. This frame relay management protocol is referred to as the Local Management Interface (LMI). Its function is to provide information about PVC status. Originally, the frame relay specification did not provide for this kind of status. Since then, a method for LMI has been developed and has been incorporated into the ANSI and CCITT standards.
Frame Relay Management
Three levels of management control exist for NetWare MultiProtocol Router frame relay support used to link a router to a frame relay network:
Local Management
Frame relay Network Management
Network Congestion Control Management (discussed earlier)
Local Management. Local management of Novell's MultiProtocol Router implementation of frame relay is accomplished using a link management protocol - either the LMI or the Annex D protocol - to exchange status information between the router and the frame relay network.
LMI also defines a number of optional features to simplify implementation or enhance operation. It learns about all devices that are accessible on the frame relay network, and exchanges "keep-alive" packets that are sent periodically. The keep-alive packet is a continuous link confidence test at the access interface, based on sequence number or counters that are exchanged between the frame relay network and the router.
LMI and Annex D provide a frame relay implementation that addresses signaling and other network management functions.
LMI Operations. Based on ISDN DSS1 (Digital Signaling System 1), LMI is widely implemented on most frame relay equipment. It provides the following support:
Notification of the addition, deletion and presence of a PVC
Verification of link integrity using keep-alive sequence number exchanges
Notification of the availability of a configured PVC
Annex D Operations. Annex D provides for the following in-channel signaling procedures:
Notification of the addition and deletion of a PVC
Verification of link integrity using keep-alive sequence number exchanges
Notification of the availability of a configured PVC
Frame Relay Network Management
Frame relay network management is implemented within the network by the frame relay Management Information Base (MIB) to support the Simple Network Management Protocol (SNMP). Managed objects are organized into three tables:
Frame relay Data-Link Connection Management Interfacetable, which contains data-link connection management interface parameters of a frame relay interface attachment.
Frame relay circuit table, which contains information about a virtual circuit. The virtual circuit is identified byan interface index and the corresponding DLCI. Virtual circuits associated with the same frame relay interface attachment are contained in one table.
Frame relay error table, which contains informationabout errors that occurred on a frame relay interface attachment.
Network Congestion Control
A frame relay network supports congestion control procedures to prevent performance degradation and to maintain acceptable quality of service. Congestion control procedures have been discussed in detail earlier in this AppNote. Refer to your frame relay carrier or switch vendor to determine vendor-specific congestion control features.
Frame Relay Services
The first frame relay service was offered in the early 1990s from companies such as AT&T, US Sprint, BT North American (now part of MCI), Wiltel, and CompuServe. These companies placed frame relay nodes throughout major cities in the United States and provided access to these nodes (at the point of presence, or POP) by local access line. Connections into POP are purchased from local telecommunications companies. Customers purchase a subscription to the frame relay service, as well as the access line, from the local telecommunications company (speeds range between 56 kbps and 1.544 Mbps).
With leased lines, users buy capacity and availability, making it easy to make price comparisons because every carrier offering can be reduced to these two services. With frame relay, carriers don't sell the service based on any structured standards. There are thus two main reasons why comparing frame relay pricing can be difficult.
First, some carriers base their service on a committed information rate (CIR), which is the average data rate over time; committed burst size, which is the maximum size of a single traffic burst; and burst excess, which is the amount of data the network agrees to try to carry in addition to the committed burst. Users should not purchase frame relay service based only on CIR because carriers are inconsistent in the way they define CIR. It's easy to get a quote from one service provider with a totally different CIR definition.
Second, users need to understand other factors involved in telecommunications companies' implementation of frame relay and how many different ways a service can be provided. As an example of this, a user could have one CIR at 56kbps and a committed burst rate of 10,000 bits, and another with the same CIR and a committed burst size of 1,000 bits. The first one gives the user the ability to send data continually for nearly two-tenths of a second, compared to the second which allows data throughput at two one-hundredths of a second.
So how does a user know which configuration to use? Most telcos provide "Management Tools" as an added service. These tools can determine your utilization on the WAN. MCI offers a service that allows users to bring in their equipment to test performance in an actual frame relay network. Other service providers include a detailed summary with your bill that reflects traffic loads broken down into time intervals. This information can be very helpful in tailoring your service. Other methods can be used in measuring traffic prior to going out onto the WAN.
It is important for the user subscribing to a frame relay service to set up a service level agreement with the telco of choice. The agreement should define the CIR, the committed burst size, burst access, delay, and discard rate. It should also allow variations on the base values.
Tariffing Structure Terminology
The following definitions cover the most common terms used in defining the tariffing structure for frame relay service. An understanding of the terms used will be helpful.
Committed Information Rate (CIR). This is the basic level of tariffing which is common to all services and is defined by the international ANSI and CCITT frame relay standards. Variations of definitions depend on the service provider, in general, represent the maximum bandwidth a user can burst and still be guaranteed delivery of all data. Transmissions exceeding the CIR are subject to discard, depending on the use of the DE bit.
Several methods can be used with CIR:
Committed Information Rate (CIR). This is the minimum sustained rate at which the frame relay provider agrees to transfer data.
Committed Burst Size (Bc). This is the minimum sustained rate at which the frame relay provider agrees to transfer data.
The maximum number of bits that the network agrees to transfer during any time interval "T", as calculated by the following formula:
T=Bc/CIR
This formula states that the time interval over which the rate is measured is proportional the burst size. For example, consider a network with a committed burst size of 256 kbps and a committed information rate of 64 kbps:
T=256 kbps/64kb or 4 seconds
The network will make its best effort to deliver 256k bits of data over any 4-second period, or it will support an average user rate of 64 kbps averaged over a 4-second period.
Burst Rate. The difficulty with burst rate is that there is no requirement for the service provider to deliver data that exceeds the CIR.
PVC. Telcos charge per PVC. Usually the cost is one flat rate per month.
Port Charge. Similar to PVC, this is typically a minimal rent charge for the physical port in a frame relay network.
Currently, frame relay implementations offer only PVCs. Your frame relay provider provides the PVC Management Protocol that their network uses. Something to look for in the future is frame relay support with SVCs.
NetWare MultiProtocol Router
Novell's NetWare MultiProtocol Router (MPR) software provides a software-based router application that can be run on any 386, 486, or Pentium-based hardware system. Customers can also migrate the routing capabilities of their existing servers to MPR. These platforms provide a scalable solution that addresses the ever changing and growing needs of the internetworking market. Novell's MPR products support the concurrent routing of IPX, TCP/IP, and AppleTalk across both local and wide area networks. Additionally, they offer support for source route bridging and the industry standard Data Link Switching (DLSw) for bridging and routing SNA and NetBIOS applications across interconnected LANs and WANs. LAN topologies supported include Ethernet, token ring, FDDI, fast Ethernet, and ARCnet. WAN services supported include dedicated leased lines (1200 bps up to 2.048 mbps), X.25, frame relay, SMDS, and dial-on-demand across low-cost analog circuits.
NetWare MPR's Frame Relay Services
The WAN Extensions module is an add-on module for the BranchLink and Enterprise Router products. It provides connection services to a majority of frame relay networks, both public and private. The WAN Extensions module has been certified by most of the frame relay service providers, and offers a cost-effective way to connect multiple branch office sites to the corporate site. NetWare MultiProtocol Router solutions comply with the frame relay standards and offer an interoperable approach for natively routing TCP/IP, IPX, and AppleTalk traffic, and for natively bridging NetBIOS and SNA applications (compliant with RFC 1490).
Several of the major benefits of frame relay services include the off-loading of the WAN administration to the telco service provider, a reduction in the overall number of WAN router ports required, and low-delay services that scale from 56 Kbps to 1.544 Mbps.
Other highlights for frame relay include the following:
Easy configuration interface
PVC management (NetWare MultiProtocol Router software supports both LMI and Annex D protocols for PVC management, which allows the sites connectivity to all frame relay network providers)
Supports maximum frame size up to 4520 octets.
Supports FECN and BECN indications (read-only for development support in newer protocols)
Supports DE (Discard Eligibility) bit
Supports up to 1024 virtual circuits per port (maximum of 975 PVCs for data transfer)
Supports back-to-back testing mode
Supports RFC 1490 multiprotocol encapsulation over NetWare Link/Frame Relay
Instrumented to SNMP Agent
Supports frame relay MIB
Interoperates with other standards-based routers, such as those from Cisco Systems, IBM, Proteon, and Wellfleet
Frame Relay Trace Utility
NetWare MultiProtocol Router includes a frame relay trace utility (FRTRACE). FRTRACE is a NetWare Loadable Module (NLM) file that provides access to frame relay trace information to monitor the operation of the frame relay link. FRTRACE can be used locally at the router or server console, or remotely from any workstation running the remote console utility (RCONSOLE). Figure 6 shows a sample display of an actual packet trace for frame relay.
Figure 7: Sample screen from the FRTRACE utility.
Tools like FRTRACE, and others included within NetWare, provide debugging capabilities that are cost-effective because they eliminate the need to purchase expensive specialized hardware. The following features in FRTRACE are designed to assist you and Novell support engineers in capturing any problems that occur during communication over the frame relay WAN:
Real-time protocol trace facility
Capture to RAM (for high-speed, high utilization link traffic) or to disk (for moderate traffic)
Real-time capture trace playback for RAM or disk
The data collected through these facilities can be faxed or sent to Novell for analysis.
Other functions included in FRTRACE are designed for your telecommunications company:
Network interface level statistics (with throughput calculations)
Virtual circuit level statistics
Network interface summary information
Raw-mode display option
Decode options of LMI (Decode 1) or Annex D (Decode 2)
Upper-level protocol encapsulation decode option
Support for all links and protocols
Information produced through FRTRACE can be viewed in common formats known by telco engineers.
Additional WAN Service Offerings
NetWare MultiProtocol Router products support a wide range of WAN options, enabling network managers to choose the most cost-effective WAN service for connecting their remote offices together. These services include the following.
Leased-line Services. NetWare MultiProtocol Router products provide communications over dedicated leased lines using the industry-standard Point to Point Protocol (PPP). Connection services ranging from low-speed, analog grade lines to high-speed T1 digital circuits (1200 bps to 2.048 Mbps) are all supported. This implementation assures multivendor interoperability between sites. This allows network managers the option of connecting NetWare MultiProtocol Routers to a wide range of third-party routers, including products from Cisco, 3Com, Bay Networks, and other PPP-compliant offerings.
Dial-on-Demand Services. Dial-on-demand routing services provide a low-cost approach for connecting branch offices together. When excess traffic is detected and needs to be forwarded across the WAN, a temporary connection is established between two NetWare MultiProtocol Routers. This service is commonly connected to standard voice-grade lines and is available with the both the NetWare BranchLink and Enterprise routers.
X.25 Services. Integrated with either the BranchLink or Enterprise Router, the WAN Extensions module provides connection services across both public and private X.25 networks. This combined solution offers a wide variety of X.25 parameter settings, enabling network managers to implement the most effective X.25 service for their companies. The WAN Extensions module includes a set of standard X.25 profiles for the major packet switched networks worldwide.
Bandwidth-Efficient NLSP Routing. In response to the growing demand for bandwidth-efficient wide area communication solutions, Novell has developed the NetWare Link Services Protocol (NLSP) for IPX. This link state routing protocol eliminates RIP/SAP broadcasts across the wide area network, provides fast convergence when the status of the network changes, and offers better scalability for large, routed IPX networks. With the elimination of RIP/SAP broadcasts across the wide area network, more bandwidth is available for the transmission of user data. This increases user response time, often reduces the need for more bandwidth capacity, and provides a more cost-efficient method for sending administrative data back and forth between the routers. Faster convergence increases the reliability of the network - compared to RIP, NLSP updates and converges the network three times faster.
NLSP is an integral part of the NetWare MultiProtocol Router products as well as the NetWare 4.1 operating system. It has quickly become the preferred approach for routing IPX traffic across the WAN. With the elimination of RIP/SAP updates across the WAN, network managers have noticed a substantial reduction in overhead traffic, a notable increase in performance, and a reduction and the overall bandwidth required. Additionally, NLSP provides load balancing across equally-weighted segments. NetWare MultiProtocol Router products fully comply with the NLSP open standard which is being endorsed by a majority of router vendors, and they have become the benchmark in the industry for testing interoperability.
Cost-Effective OSPF Routing. Open Shortest Path First (OSPF) is a link state routing protocol specifically designed for large TCP/IP internetworks. OSPF provides faster convergence than RIP, and minimizes the number and size of administrative packets sent when updating the network. NetWare MultiProtocol Router products provide an industry standard implementation of OSPF, and are interoperable with other OSPF-compliant routers.
Performance Optimization Across WANs
One of the largest, reoccurring expenses related to wide area communications are the monthly line charges billed by the wide area service provider. Typically these costs can represent as much as 75 to 85 percent of the total cost of ownership of a router, when calculated over two to three year period. The data compression and packet filtering bandwidth optimization features provided by both the BranchLink and Enterprise Routers reduce these expenses by minimizing the overall bandwidth required, and by increasing the efficiencies of the existing bandwidth already in place.
Data Compression. The data compression feature provided by NetWare MultiProtocol Router products offers up to a 4:1 traffic compression ratio. This option is enabled across PPP links, which provides a standard implementation for compressing both data and packet headers across wide area networks. The NetWare MultiProtocol Router data compression option works with all supported protocols, including IPX, TCP/IP, AppleTalk, and source route bridged data.
When data compression is enabled, network managers will typically find that they can transmit up to four times as many packets through their low- to medium-speed (56 to 256 Kbps) wide area links. This type of packet increase often reduces the need to move to higher speed links, and increases the overall response time by increasing the number of packets transmitted over the same period of time.
Packet Filtering. NetWare MultiProtocol Router products provide comprehensive filtering with packet, service, and route settings. These settings can be applied on a per-port basis, or on a global level. Commonly, network managers will use these options to restrict the advertisements of local routes and services across the wide area links. This reduction of advertisements increases the availability of these wide area links for user generated data.
Additionally, network managers will use the filtering options for controlling access to critical resources within the network. The per-port, per-address, and per-protocol configuration options offer the control mechanisms for controlling this access. Network managers can quickly identify individuals and workgroups that need access to specified resources, and grant rights to only these individuals, by allowing only the packets addressed to them to be routed across identified ports within the NetWare MultiProtocol Router products.
Enhanced IBM Communications
Source Route Bridging. The NetWare BranchLink and Enterprise Router products provide IBM compatible source-route bridging for internetworking SNA and NetBIOS applications together across local and wide area networks. Source route bridging runs concurrently with TCP/IP, IPX, and AppleTalk routing. This increases the overall versatility of NetWare MultiProtocol Router solutions, allowing network managers to combine LAN and SNA applications together across the same wide area network. NetWare MultiProtocol Routers support source route bridging across frame relay, X.25, dedicated leased line, and standard analog wide area services.
The NetWare MultiProtocol Router source route bridging implementation is compatible with IBM's source route bridging spanning tree algorithm. The software filters packets by hop count, source ring number, and protocol ID by interface. Additionally, IBM's LAN Network Manager is supported and provides a path for reporting local station and token ring segments faults to NetView.
SNA Extensions. Offered as an add-on module for both the BranchLink and Enterprise Router products, SNA Extensions provides a solution for routing SNA applications (NetBIOS and LLC2) across existing TCP/IP and IPX backbones. Industry standard Data Link Switching (DLSw) is used to encapsulate SNA packets within TCP/IP or IPX, and provides an interoperable approach for routing these packets to other routers within the network.
DLSw substantially reduces the amount SNA administrative traffic across the WAN by "spoofing" discovery and keep-alive packets. The spoofing of this traffic increases the availability of the wide area network for user applications. DLSw addresses the need to consolidate both SNA- and LAN-based applications onto the same backbone. Novell has extended the DLSw functionality to include IPX backbones as well as TCP/IP backbones.
Further, the SNA Extensions module enhances the communic-ations across an existing SNA backbone by enabling the routing of TCP/IP, IPX, and AppleTalk protocols. This feature is commonly used by SNA network administrators who have not installed a TCP/IP or IPX backbone across a wide area network, and who have a need to exchange e-mail, transfer files, or manage LAN-based devices from a central site. SNA Extensions extends the functionality of the SNA backbone to LAN-based applications.
Simplified Configuration, Installation and Remote Management
NetWare MultiProtocol Router products include a menu driven configuration utility (INETCFG) that greatly reduces the overall time required to install, configure, and manage these products on a daily basis. Specifically, network managers use the INETCFG utility for quickly changing system parameters, for modifying address tables, for activating and disabling WAN connections, and for turning filters on and off. Additionally, full diagnostics for TCP/IP, IPX, and AppleTalk, protocols are provided as a configurable option to help quickly resolve any installation or operational errors.
NetWare MultiProtocol Router products provide remote installation and configuration procedures. This allows network managers to install, upgrade, and configure remotely-located BranchLink and Enterprise Routers from a central site. This functionality substantially reduces the administration expenses associated with on-site visits, training, and administration.
NetWare MultiProtocol Router products support the Simple Network Management Protocol (SNMP) MIB II. These routers can be managed using any standard SNMP-based network management console, including Novell's NetWare Management System (NMS). Additional MIBs supported include AppleTalk (RFC1243) and source route bridging (RFC1286). Alerts, alarms, and SNMP traps can be set to respond to a local SNMP management station, or they can be sent to a central site.
Access to the Internet
One of the primary commercial functionsNetWare MultiProtocol Router products is to provide access to the Internet. Typically, this is accomplished through a frame relay or dedicated leased line connection. NetWare MultiProtocol Router products unlock the resources of the Internet for commercial and private applications. Growing services supported by these products include worldwide server web access, electronic e-mail exchange between different companies, and remote access through the Internet to other offices. By enabling the NetWare MultiProtocol Router filtering options, network managers can protect access to critical company resources by Internet hackers, and restrict user access to the Internet within their own company.
Conclusion
Frame relay is a simplified form of packet-mode switching, optimized for transporting today's protocol-oriented data. The result of this simplification is that frame relay offers higher throughput, while still retaining the bandwidth and equipment efficiencies that come from having multiple virtual circuits share a single port and transmission facility. Thus, the use of frame relay can:
Reduce the cost of transmission facilities and equipment
Provide increased performance, reliability, and application response time
Increase interoperability through well-defined international standards
A major reason for the high level of interest in frame relay is that it is a technology that has been developed in response to a clear market need. With the proliferation of powerful end-point devices (such as PCS and workstations) operating with intelligent protocols (such a TCP/IP, XNS and DECnet), users are seeking WAN communication methods that offer higher throughput and more cost-effective use of digital transmission lines. With that need in mind, frame relay has been developed and standardized to have precisely the combination of characteristics needed by today's corporate networks.
Coupled with the NetWare MultiProtocol Router, frame relay provides customers a flexible, highly manageable solution at a reasonable cost. Frame relay is just one of many WAN alternatives available. Given the right planning, it will provide users with efficient high-bandwidth connectivity now and into the future.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.