Computer Security - Hacking And Hackers Information Security Resource Portal security hacking hackers hacker news downloads crackers virus virii viruses hacked webpages DOS denial of service hacking files hack files hack links hacking links encryption spoofing news texts password crackers port monitors key logger phreaking boxes wardialers patches exploits computer security network security privacy encryption computer crime firewallsinformation warfare intrusion detection hackers elec
 | Our News Resources have been upgraded Check out the latest news by clicking HERE |
| The Security Portal for Information System Security Professionals The most comprehensive computer and network security resource on the Internet for Information System Security Professionals - Says Yahoo Editors | |
Audit - Detect Network Intrusions | Frame Relay Information Resources IntroductionFrame Relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI reference model. Frame Relay originally was designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well. This chapter focuses on Frame Relay's specifications and applications in the context of WAN services. Frame Relay is an example of a packet-switched technology. Packet-switched networks enable end stations to dynamically share the network medium and the available bandwidth. The following two techniques are used in packet-switching technology: • • Variable-length packets are used for more efficient and flexible data transfers. These packets are switched between the various segments in the network until the destination is reached. Statistical multiplexing techniques control network access in a packet-switched network. The advantage of this technique is that it accommodates more flexibility and more efficient use of bandwidth. Most of today's popular LANs, such as Ethernet and Token Ring, are packet-switched networks. Frame Relay often is described as a streamlined version of X.25, offering fewer of the robust capabilities, such as windowing and retransmission of last data that are offered in X.25. This is because Frame Relay typically operates over WAN facilities that offer more reliable connection services and a higher degree of reliability than the facilities available during the late 1970s and early 1980s that served as the common platforms for X.25 WANs. As mentioned earlier, Frame Relay is strictly a Layer 2 protocol suite, whereas X.25 provides services at Layer 3 (the network layer) as well. This enables Frame Relay to offer higher performance and greater transmission efficiency than X.25, and makes Frame Relay suitable for current WAN applications, such as LAN interconnection. Frame Relay StandardizationInitial proposals for the standardization of Frame Relay were presented to the Consultative Committee on International Telephone and Telegraph (CCITT) in 1984. Because of lack of interoperability and lack of complete standardization, however, Frame Relay did not experience significant deployment during the late 1980s. A major development in Frame Relay's history occurred in 1990 when Cisco, Digital Equipment Corporation (DEC), Northern Telecom, and StrataCom formed a consortium to focus on Frame Relay technology development. This consortium developed a specification that conformed to the basic Frame Relay protocol that was being discussed in CCITT, but it extended the protocol with features that provide additional capabilities for complex internetworking environments. These Frame Relay extensions are referred to collectively as the Local Management Interface (LMI). Since the consortium's specification was developed and published, many vendors have announced their support of this extended Frame Relay definition. ANSI and CCITT have subsequently standardized their own variations of the original LMI specification, and these standardized specifications now are more commonly used than the original version. Internationally, Frame Relay was standardized by the International Telecommunication Union—Telecommunications Standards Section (ITU-T). In the United States, Frame Relay is an American National Standards Institute (ANSI) standard. Frame Relay DevicesDevices attached to a Frame Relay WAN fall into the following two general categories: • • DTEs generally are considered to be terminating equipment for a specific network and typically are located on the premises of a customer. In fact, they may be owned by the customer. Examples of DTE devices are terminals, personal computers, routers, and bridges. DCEs are carrier-owned internetworking devices. The purpose of DCE equipment is to provide clocking and switching services in a network, which are the devices that actually transmit data through the WAN. In most cases, these are packet switches. Figure 10-1 shows the relationship between the two categories of devices. Figure 10-1 DCEs Generally Reside Within Carrier-Operated WANs 
The connection between a DTE device and a DCE device consists of both a physical layer component and a link layer component. The physical component defines the mechanical, electrical, functional, and procedural specifications for the connection between the devices. One of the most commonly used physical layer interface specifications is the recommended standard (RS)-232 specification. The link layer component defines the protocol that establishes the connection between the DTE device, such as a router, and the DCE device, such as a switch. This chapter examines a commonly utilized protocol specification used in WAN networking: the Frame Relay protocol. Frame Relay Virtual CircuitsFrame Relay provides connection-oriented data link layer communication. This means that a defined communication exists between each pair of devices and that these connections are associated with a connection identifier. This service is implemented by using a Frame Relay virtual circuit, which is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN). Virtual circuits provide a bidirectional communication path from one DTE device to another and are uniquely identified by a data-link connection identifier (DLCI). A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network. This capability often can reduce the equipment and network complexity required to connect multiple DTE devices. A virtual circuit can pass through any number of intermediate DCE devices (switches) located within the Frame Relay PSN. Frame Relay virtual circuits fall into two categories: switched virtual circuits (SVCs) and permanent virtual circuits (PVCs). Switched Virtual CircuitsSwitched virtual circuits (SVCs) are temporary connections used in situations requiring only sporadic data transfer between DTE devices across the Frame Relay network. A communication session across an SVC consists of the following four operational states: • • • • After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged. It is expected that SVCs will be established, maintained, and terminated using the same signaling protocols used in ISDN. Few manufacturers of Frame Relay DCE equipment support switched virtual circuit connections. Therefore, their actual deployment is minimal in today's Frame Relay networks. Previously not widely supported by Frame Relay equipment, SVCs are now the norm. Companies have found that SVCs save money in the end because the circuit is not open all the time. Permanent Virtual CircuitsPermanent virtual circuits (PVCs) are permanently established connections that are used for frequent and consistent data transfers between DTE devices across the Frame Relay network. Communication across a PVC does not require the call setup and termination states that are used with SVCs. PVCs always operate in one of the following two operational states: • • DTE devices can begin transferring data whenever they are ready because the circuit is permanently established. Data-Link Connection IdentifierFrame Relay virtual circuits are identified by data-link connection identifiers (DLCIs). DLCI values typically are assigned by the Frame Relay service provider (for example, the telephone company). Frame Relay DLCIs have local significance, which means that their values are unique in the LAN, but not necessarily in the Frame Relay WAN. Figure 10-2 illustrates how two different DTE devices can be assigned the same DLCI value within one Frame Relay WAN. Figure 10-2 A Single Frame Relay Virtual Circuit Can Be Assigned Different DLCIs on Each End of a VC 
Congestion-Control MechanismsFrame Relay reduces network overhead by implementing simple congestion-notification mechanisms rather than explicit, per-virtual-circuit flow control. Frame Relay typically is implemented on reliable network media, so data integrity is not sacrificed because flow control can be left to higher-layer protocols. Frame Relay implements two congestion-notification mechanisms: • • FECN and BECN each is controlled by a single bit contained in the Frame Relay frame header. The Frame Relay frame header also contains a Discard Eligibility (DE) bit, which is used to identify less important traffic that can be dropped during periods of congestion. The FECN bit is part of the Address field in the Frame Relay frame header. The FECN mechanism is initiated when a DTE device sends Frame Relay frames into the network. If the network is congested, DCE devices (switches) set the value of the frames' FECN bit to 1. When the frames reach the destination DTE device, the Address field (with the FECN bit set) indicates that the frame experienced congestion in the path from source to destination. The DTE device can relay this information to a higher-layer protocol for processing. Depending on the implementation, flow control may be initiated, or the indication may be ignored. The BECN bit is part of the Address field in the Frame Relay frame header. DCE devices set the value of the BECN bit to 1 in frames traveling in the opposite direction of frames with their FECN bit set. This informs the receiving DTE device that a particular path through the network is congested. The DTE device then can relay this information to a higher-layer protocol for processing. Depending on the implementation, flow-control may be initiated, or the indication may be ignored. Frame Relay Discard EligibilityThe Discard Eligibility (DE) bit is used to indicate that a frame has lower importance than other frames. The DE bit is part of the Address field in the Frame Relay frame header. DTE devices can set the value of the DE bit of a frame to 1 to indicate that the frame has lower importance than other frames. When the network becomes congested, DCE devices will discard frames with the DE bit set before discarding those that do not. This reduces the likelihood of critical data being dropped by Frame Relay DCE devices during periods of congestion. Frame Relay Error CheckingFrame Relay uses a common error-checking mechanism known as the cyclic redundancy check (CRC). The CRC compares two calculated values to determine whether errors occurred during the transmission from source to destination. Frame Relay reduces network overhead by implementing error checking rather than error correction. Frame Relay typically is implemented on reliable network media, so data integrity is not sacrificed because error correction can be left to higher-layer protocols running on top of Frame Relay. Frame Relay Local Management InterfaceThe Local Management Interface (LMI) is a set of enhancements to the basic Frame Relay specification. The LMI was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation. It offers a number of features (called extensions) for managing complex internetworks. Key Frame Relay LMI extensions include global addressing, virtual circuit status messages, and multicasting. The LMI global addressing extension gives Frame Relay data-link connection identifier (DLCI) values global rather than local significance. DLCI values become DTE addresses that are unique in the Frame Relay WAN. The global addressing extension adds functionality and manageability to Frame Relay internetworks. Individual network interfaces and the end nodes attached to them, for example, can be identified by using standard address-resolution and discovery techniques. In addition, the entire Frame Relay network appears to be a typical LAN to routers on its periphery. LMI virtual circuit status messages provide communication and synchronization between Frame Relay DTE and DCE devices. These messages are used to periodically report on the status of PVCs, which prevents data from being sent into black holes (that is, over PVCs that no longer exist). The LMI multicasting extension allows multicast groups to be assigned. Multicasting saves bandwidth by allowing routing updates and address-resolution messages to be sent only to specific groups of routers. The extension also transmits reports on the status of multicast groups in update messages. Frame Relay Network ImplementationA common private Frame Relay network implementation is to equip a T1 multiplexer with both Frame Relay and non-Frame Relay interfaces. Frame Relay traffic is forwarded out the Frame Relay interface and onto the data network. Non-Frame Relay traffic is forwarded to the appropriate application or service, such as a private branch exchange (PBX) for telephone service or to a video-teleconferencing application. A typical Frame Relay network consists of a number of DTE devices, such as routers, connected to remote ports on multiplexer equipment via traditional point-to-point services such as T1, fractional T1, or 56-Kb circuits. An example of a simple Frame Relay network is shown in Figure 10-3. Figure 10-3 A Simple Frame Relay Network Connects Various Devices to Different Services over a WAN 
The majority of Frame Relay networks deployed today are provisioned by service providers that intend to offer transmission services to customers. This is often referred to as a public Frame Relay service. Frame Relay is implemented in both public carrier-provided networks and in private enterprise networks. The following section examines the two methodologies for deploying Frame Relay. Public Carrier-Provided NetworksIn public carrier-provided Frame Relay networks, the Frame Relay switching equipment is located in the central offices of a telecommunications carrier. Subscribers are charged based on their network use but are relieved from administering and maintaining the Frame Relay network equipment and service. Generally, the DCE equipment also is owned by the telecommunications provider. The majority of today's Frame Relay networks are public carrier-provided networks. Private Enterprise NetworksMore frequently, organizations worldwide are deploying private Frame Relay networks. In private Frame Relay networks, the administration and maintenance of the network are the responsibilities of the enterprise (a private company). All the equipment, including the switching equipment, is owned by the customer. Frame Relay Frame FormatsTo understand much of the functionality of Frame Relay, it is helpful to understand the structure of the Frame Relay frame. Figure 10-4 depicts the basic format of the Frame Relay frame, and Figure 10-5 illustrates the LMI version of the Frame Relay frame. Flags indicate the beginning and end of the frame. Three primary components make up Standard Frame Relay FrameStandard Frame Relay frames consist of the fields illustrated in Figure 10-4. Figure 10-4 Five Fields Comprise the Frame Relay Frame 
The following descriptions summarize the basic Frame Relay frame fields illustrated in Figure 10-4. • • – – – – Forward-explicit congestion notification (FECN) is a single-bit field that can be set to a value of 1 by a switch to indicate to an end DTE device, such as a router, that congestion was experienced in the direction of the frame transmission from source to destination. The primary benefit of the use of the FECN and BECN fields is the capability of higher-layer protocols to react intelligently to these congestion indicators. Today, DECnet and OSI are the only higher-layer protocols that implement these capabilities. Backward-explicit congestion notification (BECN) is a single-bit field that, when set to a value of 1 by a switch, indicates that congestion was experienced in the network in the direction opposite of the frame transmission from source to destination. Discard eligibility (DE) is set by the DTE device, such as a router, to indicate that the marked frame is of lesser importance relative to other frames being transmitted. Frames that are marked as "discard eligible" should be discarded before other frames in a congested network. This allows for a basic prioritization mechanism in Frame Relay networks. • • LMI Frame FormatFrame Relay frames that conform to the LMI specifications consist of the fields illustrated in Figure 10-5. Figure 10-5 Nine Fields Comprise the Frame Relay That Conforms to the LMI Format 
The following descriptions summarize the fields illustrated in Figure 10-5. • • • • • • – – • – – – • SummaryFrame Relay is a networking protocol that works at the bottom two levels of the OSI reference model: the physical and data link layers. It is an example of packet-switching technology, which enables end stations to dynamically share network resources. Frame Relay devices fall into the following two general categories: • • Frame Relay networks transfer data using one of the following two connection types: • • The DLCI is a value assigned to each virtual circuit and DTE device connection point in the Frame Relay WAN. Two different connections can be assigned the same value within the same Frame Relay WAN—one on each side of the virtual connection. In 1990, Cisco Systems, StrataCom, Northern Telecom, and Digital Equipment Corporation developed a set of Frame Relay enhancements called the Local Management Interface (LMI). The LMI enhancements offer a number of features (referred to as extensions) for managing complex internetworks, including the following: • • • Some review QuestionsQ—What kind of technology is Frame Relay? A—Packet-switched technology. Q—Name the two kinds of packet-switching techniques discussed in this chapter, and briefly describe each. A—1. In variable-length switching, variable-length packets are switched between various network segments to best use network resources until the final destination is reached. 2. Statistical multiplexing techniques essentially use network resources in a more efficient way, Q—Describe the difference between SVCs and PVCs. A—A SVC, switched virtual circuit, is created for each data transfer and is terminated when the data transfer is complete. PVC, permanent virtual circuit, is a permanent network connection that does not terminate when the transfer of data is complete. Previously not widely supported by Frame Relay equipment, SVCs are now used in many of today's networks. Q—What is the data-link connection identifier (DLCI)? A—The DLCI is a value assigned to each virtual circuit and DTE device connection point in the Frame Relay WAN. Two different connections can be assigned the same value within the same Frame Relay WAN—one on each side of the virtual connection. Q—Describe how LMI Frame Relay differs from basic Frame Relay. A—LMI Frame Relay adds a set of enhancements, referred to as extensions, to basic Frame Relay. Key LMI extensions provide the following functionality: global addressing, virtual circuit status messages, and multicasting. Frame Relay a further explanation...by Arthur Cooper Frame Relay is a technology that grew from an existing protocol and the need to improve upon it. The need in this case was to provide cheap, reliable network services for Local Area Network (LAN) users who need to pass data back and forth between other LANs that they do business with on a daily basis. This data passing between LANs is where Wide Area Networking (WAN) technology comes into play. In order to understand the background of Frame Relay technology, it's necessary to take a trip down the path of network history and the creation of the X.25 protocol. Frame Relay: The Technology that Grew from X.25The history of data networks begins in the 1960s in the United States. At that time, most computer systems were standalone behemoths that had no reason to interact with other computers. The U.S. government created the Defense Advanced Research Projects Agency (DARPA), which was mandated to fund projects concerning the development of emerging technologies. One idea was to connect dissimilar computer systems to each other to simplify the task of sharing data between those systems. Scientists involved with DARPA began to look at creating a standard protocol to be used between computer systems. In 1969, using four network switches or nodes, the first internetwork (network of networks) became a reality. This network was called the Advanced Research Projects Agency Network (ARPANET), and it was the seed that created today's modern Internet system. Frame Relay grew out of this technology. The ARPANET was responsible for the creation of a new internetwork protocol. This protocol was called ARPANET 1822, but it soon became known as X.25 (a standard name assigned by the International Telegraph and Telephone Consultative Committee [CCITT]). X.25 was the original packet-switching scheme that grew from the old ARPANET 1822 protocol. Several factors were present in those days that are no longer a problem today. Those factors were the driving forces that made X.25 look and act the way it did. The first factor is the lack of sophistication of the computers themselves. By today's standards, these systems were anything but sophisticated. IBM's biggest and most popular machine in those days was the old IBM 360 series mainframe. The 360 was a staple among businesses that could afford computers, and it was a marvel in its day. However, the personal computers (PCs) of today hold more computing power in their small, desktop-sized cases than the old 360 computers did. All of the programs running on these old mainframes were simply used for data manipulation and storage of some type. The computers themselves were not smart enough, or capable enough, to screen the data being fed to them for accuracy. Computer programmers and operators needed to ensure that error-free data was being put into these computers. The phrase "garbage-in-garbage-out," or GIGO, was formulated at that time. GIGO meant simply that you could not expect a computer to know if the data being fed to it was useful or full of errors. If the data being fed to it was indeed "garbage," the computer would still attempt to process the data as it normally would. The results of the processing would, of course, be of no value, and the computer itself could not be faulted for producing garbage from garbage. The second factor that drove X.25's development was the quality of telephone lines and connections. The entire Public Switched Telephone Network (PSTN) was composed of mostly copper wire between switch points, and the old Frequency Division Multiplex (FDM) microwave radio systems that carried telephone signals over greater distances were prone to thermal noise and other variations in signal quality due to the equipment itself or the atmosphere these microwave signals traveled through. These two factors, unsophisticated computer systems and poor quality telephone lines, together make up a formula for failure if X.25 is not capable of rising above them. The scientists on the ARPANET understood these two factors very well, and they decided to ensure that the protocol developed for their network could overcome these two obstacles. The ARPANET 1822 protocol was the result of their labor, and it did compensate for unsophisticated computers by ensuring error-free delivery of data. X.25 performed error-checking at many levels and stops along the network's path. All of this was built into X.25 at a time when no real protocol layers or standards had been developed. Now that you know the history of X.25, let's compare X.25 and Frame Relay (FR) technology. Comparing Frame Relay to X.25Although X.25 was the father of almost all modern network protocols, it adheres well to the OSI standard in that it uses the first three layers of the reference model. Figure 17.1 shows the X.25 layers. . X.25 layers of the OSI model. These three layers are called the physical, data, and network layers. Neat things are happening at each layer, as you will see later on, but the important thing to know is that X.25 uses these three layers at all times, and error checking occurs at each layer. X.25 actually encompasses three protocols. There is one at each layer of operation, as shown in Figure 17.2. X.25 layers and their respective protocols. At the lowest layer of X.25, the layer at which there is a physical connection between a User-to-Network Interface (UNI) and the X.25 network itself, the actual protocol used that describes how the user and network tie together is called the X.21 or X.21bis protocol. X.21 is popular in Europe, whereas X.21bis is used in the United States. This protocol describes the actual physical data connection between the UNI and the network. At the data or data link layer, X.25 uses a protocol known as Link Access Procedure Balanced (LAPB). Briefly, this is a software protocol that performs the function of decoding frames or collections of bits of information. These frames are collections of bits of information that the transmitting and receiving UNIs are trying to get passed through the network. At the highest layer of X.25, the Network or packet layer, X.25 uses a protocol known widely as the Packet Layer Protocol (PLP). This protocol ensures that the frames from the second level are assembled into packets that can then be transmitted from one end of a network to the other. Now that you have seen what X.25 is all about, what is Frame Relay? Frame Relay is simply the latest variation on the old X.25 scheme. The CCITT originally came up with the idea of using Frame Relay on Integrated Service Digital Network (ISDN) circuits. The ISDN circuits in use today are either a 2B & D arrangement or a 23B & D arrangement. The 2B & D uses 2 B, or bearer, channels that are 64Kbps circuits. The D, or delta, channel is a 16Kbps circuit used for signaling. The 23B & D is the same, except that there are actually 23 64Kbps circuits available. When the CCITT came up with the original scheme for Frame Relay, they were not too sure how popular it would be, so they originally designed it to be used on the D, or delta, channel of an ISDN circuit. As you can see, 16Kbps is not a lot of bandwidth, so this idea was scrapped rather quickly. If you take a look at Figure 17.3, you will see that Frame Relay uses only the first two layers of the OSI Reference Model. Frame Relay layers of the OSI model. The lowest layer, the physical layer, describes the connection between the UNI and the Frame Relay network. The second layer shows the data, or data link layer, and this layer is used by Frame Relay for a few needed items to be discussed later. The interesting thing to note, however, is that Frame Relay has no need for the third layer as X.25 did. Frame Relay eliminates this layer completely. Frame Relay technology makes a few assumptions about the environment it is operating within. First, it assumes that the computer systems being connected together by Frame Relay networks are by their nature intelligent devices. Second, it assumes that the telephone circuits carrying the data within a Frame Relay network are of above average, if not near-perfect, quality. Examine these assumptions individually. As you know, today's modern computer systems do not in any way resemble the old mainframe systems in use during X.25's heyday. In fact, on most LANs today, the systems in use are powerful, sophisticated PCs with sophisticated operating systems and hardware. Why did X.25 have to assume computers were not too smart? If it did not, and it allowed error-ridden data to enter the computer after it had passed through the network, the computers in those days would simply have accepted and processed the data as if nothing was wrong. Today's computer systems and LAN servers are smart enough to recognize garbage when it is being fed to them. If data being sent to a computer is incorrect, it is usually the function of the higher level peer processes in the programs themselves to recognize the bad data and request new data from the device, person, or computer providing the data. Frame Relay technology is counting on this ability to ferret out and ignore bad data. The second assumption made by Frame Relay is also a valid and arguable one. Telephone circuits and networks have become extremely sophisticated and reliable in the past five to ten years. With the advent of modern fiber connections and extremely fast and reliable switching technology, line problems are really a thing of the past when dealing with data circuits and connections through the public telephone network. Here's a quick comparison of X.25 and Frame Relay at each layer. Figure 17.4 provides a side-by-side look at the two technologies and their associated layers. Comparison of X.25 and Frame Relay layers. X.25 uses the physical layer through the implementation of the X.21 protocol discussed earlier. Frame Relay uses the physical layer in many different ways. In most cases, it will be a UNI such as a bridge or a router. X.25 uses the data, or data link, layer with a protocol known as LAPB. This is a software-driven protocol that adds a lot of overhead to the data transmission taking place in the network. Frame Relay uses only a group of two octets (8 bits) at this level. This adds very little overhead to the transmission taking place. Now look at the third level used by X.25. At the network, or packet, level, X.25 uses a device known as an X.25 Packet Assembler/Disassembler (PAD) to put all of the data into packet form. These packets, or bundles, of data contain all of the information to be transmitted through the network, but there are also overhead bits of information added by X.25 at this layer. These overhead bits include a section of bits known as the logical channel number (LCN). This number is then used by the distant end node of the X.25 network in order to identify what packets go where when receiving a sequence of packets. It should be obvious to you now that Frame Relay is not even using this third layer at all. With that in mind, the following section discusses why Frame Relay is the logical choice for network managers to use when getting data from one place to another over wide distances. Why Use Frame Relay?Before moving into a discussion of the actual workings of Frame Relay technology, consider why Frame Relay is really a smart move to make when designing a WAN/LAN interface. In this author's opinion, the two major factors to consider when making any sort of networking choice are speed and cost. With that in mind and referring once again to Figure 17.4, take a look at the speed issue of X.25 technology. As you know, there is a lot of error checking and addition of redundant bits going on at the three levels of X.25 technology. At the physical layer, the X.21 protocol does some Cyclic Redundancy Checking (CRC) of the data being passed back and forth, and this process takes time. At the data, or data link, level, X.25 uses LAPB in order to compile the data into frames. LAPB adds an enormous amount of overhead bits of information needed for general frame housekeeping as well as error detection. Even the addition of 2 bits/frame over the course of a large data transmission will slow down the transmission tremendously. As the data approaches the network, or packet, layer, X.25 stuffs in a multitude of information as it performs the compilation of frames into what are known as packets. Bits are added to ensure that adequate error detection is performed at the packet level; bits are added to number, or sequence, the packets of a single transmission; and bits are even used to signal the fact that a packet was received in error. Again, all of these additional bits will slow the transmission down a lot. How does speed relate to Frame Relay? At the physical layer, Frame Relay technology is usually a bridge or router connected to the user's LAN. There are many different physical protocols in use at this level, and Frame Relay technology does not specify a particular one to be used. Therefore, the fastest method of coupling a LAN with a bridge/router that serves as the Frame Relay network interface should, and could, be used. At the data, or data link, layer, Frame Relay uses only a 2-octet field to pass its information from one end of the network to the other. What these two octets include is discussed later in this chapter, but for the purpose of this discussion, please note the small amount of information Frame Relay includes in the frames it assembles. Don't forget that Frame Relay does not even use the third layer. Figure 17.5 compares the frames of X.25 and Frame Relay at Level 2, the data layer, of the OSI Reference Model. X.25 and Frame Relay frame comparison at Level 2 of the OSI Reference Model. Notice the larger amount of information X.25 must place in all of its frames. Now, remember that Frame Relay has finished its job at this point as far as organizing and compiling frames is concerned. X.25 will be adding more bits and overhead information at Level 3, the network layer, of the OSI reference model. You can see why Frame Relay is really a speedier alternative to X.25. The second determining factor for a network choice is cost. When Frame Relay became popular in the early 1990s, there were many companies who wanted to lead the pack and grab all of the Frame Relay customers they could. One of the recognized leaders of the pack was a company called Williams Telecommunications (WILTEL) of Oklahoma. WILTEL prided itself on being one of the largest resellers of telephone and data bandwidth to America, but it actually was, and remains pretty much so today, a collection of leased fiber connections from coast to coast. WILTEL did not own a large portion of its network in the early 1990s, but they were still able to provide excellent coverage throughout the United States. They were able to do this by leasing Right of Ways from the various railroad corporations traversing the United States. For that reason, they decided to come up with a Frame Relay network and pricing package known as WILPAK. The only problem with this was that Frame Relay was in its infancy, and none of the major network companies including AT&T, MCI, as well as Sprint and others were too sure how it should be priced and sold. Today, most companies are clear on where the tariffs of pricing Frame Relay are concerned. In other words, most companies feel they can charge based on the committed information rate. In earlier days, many companies were not sure how to "explain and package" their pricing in terms the layman could understand. However, there are still some pretty difficult-to-understand and/or strange Frame Relay pricing schemes. The moral of this story is that Frame Relay is a pay-as-you-use technology. X.25 was used primarily over expensive leased lines. Also, there was no system in place to look at the actual bandwidth being used, so X.25 lines were almost always never used to full capacity. Even when the ARPANET switched to a per/packet billing scheme for its major users, it was not very cost-effective. Frame Relay connections can be had quite cheaply today. That's really it in a nutshell. X.25 is slower and in some, if not all, cases more expensive than Frame Relay. With that in mind, it makes more sense to go with a Frame Relay network connection between LANs if at all possible. Frame Relay also has its problems. The next section of this chapter discusses the actual workings of Frame Relay step by step, including frame relay's limitations. How Frame Relay WorksFrame Relay is not difficult to understand, and for the purposes of this chapter, we shall make every attempt to use layman's terms and concepts. Frame Relay is a wide area network (WAN) technology. It also happens to be a rather fast operating technology. X.25 is almost always used at speeds below 64Kbps, but Frame Relay is being used today at T-1 and even T-3 speeds.
With speeds such as this, it is easy to see why Frame Relay is sometimes referred to as Fast Packet technology. Remember that X.25 was a packet technology that used logical channel numbers to get packets to the right addressee. X.25 did so by using Switched Virtual Circuits (SVC) and Permanent Virtual Circuits (PVC). X.25 was, and is, a full-duplex operation. This means that data is going back and forth in each direction on the network. The way X.25 got these packets delivered properly was through the use of end-to-end error and packet control. This was accomplished by the third layer used by X.25. This layer, the network layer, ensured that if a message contained 500 packets, each packet was numbered 1-500 in sequence. At the receiving end of the transmission, the X.25 node on the network would be charged with the task of reassembling the packets in the correct order. If any of the packets did not arrive in sequence, the X.25 node would have to wait for the proper packet to arrive in order to pass the entire message on to the network computer requesting the transmission. However, if any of the packets arrived with errors, the X.25 node would have to request a retransmission of errored packets from the node that originated the data transmission in the first place. This sounds good, but remember, this discussion covers factors that will eat up time during a data transmission. If the X.25 nodes are involved with error checking and retransmission requests as well as packet reassembly, then the transmission will be slowed down tremendously. Frame Relay does none of this. First of all, Frame Relay does not use LCNs in order to assign packets to a destination address. Frame Relay uses a Data Link Connection Identifier (DLCI), which is covered later. The other nice thing about Frame Relay is that it also does no end-to-end error and packet control at the third layer. All it does do is some error checking at the frame, or second, level of the OSI Reference Model. At the data layer, Frame Relay does some simple error checking, and if a frame is full of errors, it does not ask for the frame to be retransmitted by the distant end. Rather, it simply discards the frame as no good, and goes on about its business of receiving and transmitting frames. You may be wondering how frames can simply be tossed away after being determined to be laden with an error or errors. The answer relates to the sophistication levels of today's modern computers. Computers today can recognize and identify the fact that a frame was missing from the transmission. At that point, the request will be passed back through the Frame Relay network to the originator requesting the frame be sent again. Frame Relay is also full-duplex, and there is indeed two-way transmission of frames from each end to the other. However, when the request is transmitted back to the originator to retransmit the frame that was apparently discarded by the Frame Relay network due to errors, it will look like any other frame to the Frame Relay network. In other words, the Frame Relay network does not get involved with the content of the frames being transmitted over it as deeply as X.25 did. Frame Relay networks simply monitor the error checking information at the second level, and if there are errors, the network discards the errored frame or frames. This is not a big problem today, as the networks in use that carry Frame Relay transmissions are extremely stable and reliable. In all actuality, very few frames are discarded due to errors in today's modern Frame Relay networks. A much larger portion of frames are discarded due to traffic demands. The frame format used by Frame Relay at Level 2 of the OSI model is shown in Figure 17.6. Frame Relay frame structure at OSI Level 2. It's quite simple and makes a lot of sense. There are two octets used by Frame Relay at this point. These octets contain the information needed by the Frame Relay network to know where the frames are to be sent along the Frame Relay network structure. There is also some controlling information present. The first ten bits of these octets make up the DLCI. The DLCIThe DLCI refers to the actual number assigned on the Frame Relay network to the user's port or system. When buying Frame Relay service from a vendor today, the circuit the vendor provides will determine what numbers are used as DLCIs at your location. If you are using the ten bits just mentioned, there is a possibility of 1,024 address combinations.
Most of the vendors providing Frame Relay services today will use numbers between 16 and 1007 for DLCI address numbers. Assume that you have a router connected to a Frame Relay circuit provided by a vendor. On this router, there are four ports in use. The vendor may decide that port one will be assigned a DLCI of 16, port two will be assigned a DLCI of 17, and so on for the remaining two ports. In this example, there would be four DLCIs assigned to your Frame Relay termination point. At the other end of the Frame Relay network, there is obviously a system that will be communicating with your end through the network. Assume that it is another router with eight ports in use. The vendor may decide to reuse the DLCIs of 16, 17, 18, and 19 for the first four ports of this termination. Therefore, the last ports could be called 20, 21, 22, and 23. This would complete the eight port addresses. How can the numbers 16 through 19 be reused? At the first termination point, the router would not be involved in sending frames to itself, so anything numbered as 16 coming in from its local ports would be sent to the first port at the other end of the Frame Relay connection. This example may seem simple, but it explains the point that while the numbers 16 through 1007 are available on most DLCI configurations, the numbers may be used over again at each user location. The DLCI number 0 is reserved for call signaling by the Frame Relay network. Also, 1-15 and 1008-1022 are reserved at present and are not being used in most Frame Relay arrangements. DLCI address 1023 will be discussed later in this chapter. The next logical question concerns itself with how a user of Frame Relay services is able to get data destined for a distant user or LAN to the right place. Within the routers and bridges themselves, there are static routing tables. In Frame Relay, most of today's users are connecting LANs together through Frame Relay technology. These LANs are almost always using a TCP/IP address scheme of sorts. Without going into a broad discussion of how IP addresses are created, let it suffice to say that each LAN will have a unique IP address. It is the information concerning the IP address and their respective DLCI numbers that is entered into the static routing tables of routers and bridges that are in turn connected to Frame Relay networks. So, going back to the last example, if the LAN on DLCI port 16 at this end has an IP address of 207.102.88.1, the tables in the distant end's router or bridge will know that anything coming in addressed to 207.102.88.1 should be sent to DLCI 16 at this end. Now, with that discussion behind you, take a look at the concept of Committed Information Rate (CIR) and how it relates to Frame Relay. CIR and the "Leaky Bucket"The committed information rate, CIR, is the concept driving Frame Relay services and their pricing. When you purchase connectivity between your LANs from a Frame Relay vendor, they are going to help you establish a CIR rate to work with. This rate actually refers to the amount of frames you can blast down the Frame Relay pipe at any given time. Figure 17.7 shows two pails of water. Believe it or not, Frame Relay technology uses an algorithm referred to as the leaky bucket algorithm. What this algorithm states is simple. When you purchase Frame Relay bandwidth at a certain CIR rate, you are assigned a timed buffer in each switch of the network along your frame relay's circuit path. Consider these buffers to be buckets of water, and the width of the buckets can be called the time or T1 The height of the buckets can be called committed burst or B1. By using these two symbols, you can see that the CIR rate would be equal to: CIR = B1 / T1. Here's what this equation is saying. If the burst of data you are transmitting is small enough to be divided equally by the time of the buckets, or buffers, within each switch along the Frame Relay network, the data will be transmitted with no discarding of frames. In simpler terms, if you have been given a CIR rate of 64Kbps, and you transmit a burst of 56Kbps, this will divide by the time (T1) which is actually a 1, and it will equal, of course, 56Kbps. Because this is smaller than the CIR rate you have been given, this burst of data should move through all of the switches in the Frame Relay network without any frames being discarded. Frame relay's bucket algorithm. Why is this math even needed? When you buy a Frame Relay circuit with a CIR rate of 64 or 128Kbps, you are gambling that your data may actually hover close to that figure at all times. Further, you are gambling that your data will want more bandwidth than that on several occasions. Now let's take the math a step further and explain the so-called leaky bucket. The Leaky Bucket ItselfWhenever a customer's CIR rate has been surpassed at any switch within the Frame Relay network, there is a bit called the Discard Eligibility (DE) bit (refer to Figure 17.6) that will be set to a 1 in all of the frames above the CIR. As these frames move through the network, they may get discarded if traffic is heavy and the switch is in a position to meet the CIR rate only. The neat thing about Frame Relay is the so-called second, or leaky, bucket. This is used whenever a customer's frames have exceeded the CIR rate, and the DE bit has been set to 1. This second bucket, the leaky bucket, is what makes Frame Relay so attractive. I will also refer to its width as T1. However, I will refer to its height as B2 for Bursts exceeding the CIR rate. This second bucket, or buffer, within the switches on a Frame Relay network will almost always be equal to the size of the first bucket. In other words, a CIR rate of 128Kbps would perhaps be able to accept bursts up to 256Kbps by filling the second bucket with data during T1, but once again, if the demands of the network are great, the second bucket, the leaky one, may have no height at all. If this is the case, then all frames above the CIR of 128Kbps will have the DE bit set to 1 and will most likely get discarded by the switch setting the DE bit to 1 or the next switch along the network path. Believe it or not, you can actually buy Frame Relay circuits today with a CIR rate of zero, but this will, of course, put all of the data you are putting on the network at risk. LANs are bursty by nature, and it behooves today's LAN administrators and network managers to attempt to determine the highest rates their LANs may need during the busy traffic periods of the average day. When using Frame Relay services, it makes sense to try a higher rate first and then lower the CIR rate after a trial period. If the lower CIR works, it may need to come lower still, but lowering the CIR can also be risky. If a vendor's network has very little traffic on it when you first purchased your service, you may actually be exceeding your CIR on a regular basis without even realizing it. If this is the case, and you lower the CIR you require at the same time the network incurs more traffic, you may well create a monster. This monster will be the continual discarding of frames by the network. Each end of your Frame Relay connection will be in crisis as it attempts to request the discarded frames, and you could actually go dead in the water if it continues. For this reason and many others, it's important to work closely with your Frame Relay vendor to ensure that the CIR rate you are paying for is cheap for you and profitable for your vendor. It's this marriage of cheap service combined with profitability for vendors that has made Frame Relay so attractive. Congestion on Frame Relay NetworksAnother area of Frame Relay that warrants explanation concerns the idea of node or traffic congestion. You have already learned how Frame Relay beats X.25 in terms of cost and speed, but there is one killer of Frame Relay services. That killer is congestion within the network itself. Frame Relay uses two methods of controlling and, hopefully, eliminating congestion. The first method is called Explicit Congestion Notification (ECN). This method is used by the switches or nodes in a Frame Relay network to notify the User-to-Network Interfaces of congestion. Most UNIs are routers or bridges, so this notification is seen by the user's router or bridge. Refer to Figure 17.6, and you will notice there are two fields called FECN and BECN. These are called Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN). Each of these fields is one bit in length, and the way they are used is as follows. If a node along the path in the Frame Relay network realizes there is some congestion being experienced for frames being transmitted to a specific DLCI, the node will set the FECN bit to a 1 for all frames heading to that DLCI address. It is hoped that the UNI connected to the DLCI at the other end will see these FECN bits set to 1 and will attempt to communicate with the UNI at the originating DLCI and slow things down a bit. At the same time, if any frames are seen going back toward the originator of the frames bound for the congested DLCI, the BECN bit will be set to a 1 on those frames. By doing so, the node is trying to tell the originator of frames bound for the congested DLCI that there is indeed congestion on the network. If a user's UNI sees the BECN bit set high to a 1, the UNI will know there is congestion going to the other end's DLCI, and hopefully the UNI will slow transmission to this congested site a bit. There are a few things that will make ECN useless. If the routers or bridges that comprise the user's UNI do not even recognize or process the FECN and BECN bits, then there is no use in using this method. Likewise, if a user has completely surpassed the CIR rate for the Frame Relay connection in question, it is possible that traffic will simply halt and go dead in the water. If this occurs, naturally the ECN bits, both forward and backward, would be of no value. For those reasons as well as others, another congestion control method is being used in some Frame Relay networks today. It is called Consolidated Link Layer Management (CLLM). This is used between the routers and nodes that comprise Frame Relay networks. It generally uses the DLCI address of 1023. The routers and nodes communicate via an established protocol called Link Management Interface (LMI) protocol. There has been a lot of discussion lately as to where LMI should be sent and used, but most Frame Relay networks are using DLCI address 1023 to pass this information between nodes and UNIs. Some newer networks are using DLCI 0, but it really does not matter which address is used as long as the LMI data gets where it needs to be. LMI will provide status messages to the UNI and node points along a Frame Relay network. These messages will contain information about what DLCIs are currently in use on the network, which ones are congested at present, and in which direction(s) the congestion is being experienced. No doubt future systems will put LMI to greater use than it is currently being used. SummaryFrame Relay will no doubt be around for the next several years. For most users of X.25 network services, it is a simple task to upgrade to a Frame Relay network arrangement. A simple change of software in a user's router or bridge can make the transition from an X.25 to a Frame Relay-based service seem invisible to the users of the connected LANs. If these software changes are implemented simultaneously with a change of vendor to one who can provide Frame Relay services, the cost savings can be extremely large. Frame Relay will provide users of network services a cheap, speedy, and reliable alternative to X.25 and other older network technologies. Some people have called Frame Relay simply a stop-gap on the way to Asynchronous Transfer Mode (ATM) technology. Although that statement may hold some truth, Frame Relay is proving itself to be anything but a stop-gap. As pricing becomes more uniform between different vendors, there will be less confusion about the CIR rate and how to determine monthly costs associated with Frame Relay. In fact, for most designers of enterprise TCP/IP networks, Frame Relay is the WAN technology of choice today.
Bibliographies of Articles and Books related to Frame Relay - CLICK HERE Because experience has proven that NO Frame Relay Network is immune to potential disaster, ADTRAN prepared this one-of-kind tutorial to help users plan their Frame Relay Network Disaster Recovery options. Furthermore, ADTRAN provides excellent resource material such as the 44 page (PDF) document that is easy to read and provides "plain answers" about frame relay network services, service level agreements and service level management, also available in HTML (sorry, Paradyne requires registration to view the HTML Version). With visual diagrams and actual frame relay service "calculations and formulas," we believe Paradyne provides the best information available about frame relay management. MicroLengend has the best tutorial we have seen on this extremely "hot" subject, IP Telephony. The visual diagrams are absolutely outstanding. Lucent VPN Quick Reference Guide (PDF) Lucent has put together this superb 98 page (PDF) VPN Quick Reference Guide, and it "smokes." Guaranteed, to get you up to "par" on VPNs. Measure Frame Relay Service Level Agreements (PDF) Paradyne provides an SLA FAQ to go along with this 6 page PDF document. SLA's have become one of the most important components of successful frame relay connectivity and this (PDF) document examines them. Additionally, Paradyne has assembled 40 questions to ask before selecting a WAN Service Level Management System. Furthermore, Inter@ctive Week has one of the best articles on securing Service Level Agreements From ISPs. ADTRAN has the best collection we have seen of concise, to-the-point technology overviews (with outstanding visual diagrams) covering such topics as Frame Relay, Local Loop, Digital Service, North American Digital Hierarchy, Dedicated Services, and Switched Service (Circuit and Packet). An absolute must read. Recommended when seeking "quick" familiarity with frame relay. Alliance Datacom in Dallas, Texas and Internet Week Newspaper offer an overview of successful frame relay deployments while defining "buzz words." Voice Over Frame Relay (VoFR) Tutorial The Institute of Electrical and Electronics Engineers, Inc. (IEEE) provide a concise and easy to read voice over frame relay tutorial. Recommended for getting a quick understanding of VoFR. The Expert Guide on Frame Relay Security For Financial Applications Technical Communications Corporation authored this unique guide with outstanding visual diagrams that will explain the benefits of frame relay for financial institutions as well as how to protect the frame relay network. Additionally, this guide will show that it is now possible to achieve the cost savings of frame relay and protect the valuable data sent over the network. Trillium Digital Systems, Inc. has assembled one of the most outstanding frame relay papers we have ever seen. Recommended for those seeking their Frame Relay Ph.D. Building A Frame Relay Network Network Computing and David Willis, Senior Technology Editor, have created a "classic tutorial" on frame relay networks. From frame relay network diagrams, selecting equipment, writing network specifications to monitoring carriers, this tutorial covers it all. Recommended as an absolute must read. The Basic Guide to Frame Relay Networking (PDF) Fabulous 86 page frame relay guide courtesy of the Frame Relay Forum, Todd Bahner of ADC Kentrox, Skip Carlson of Cabletron Systems, Anne Exter of Bell Atlantic, Mark Kaplan of Newbridge Networks, Chris Nicoll of Current Analysis, Cheryl Vandegriff Hyon of Sync Research, Jan Thibodeau of JT Communications and MCI, Visual Networks as well as Netrix. US WEST does a great job explaining frame relay. Recommended for the those first learning about frame relay technology. Voice Over Frame Relay Tutorial Mercury Technology Services explores the economics for immediate implementation of voice over frame relay because VoFR can be as inexpensive as half a cent per minute. Configuring and Troubleshooting Frame Relay Cisco has written a truly outstanding frame relay "must read." Networktroubleshooting.com has a unique website for frame relay network troubleshooting assistance, still under construction with "spotty" content. However, we believe they have a good concept that will be very helpful in the future, worth a look because of its potential. Frame Relay Newsletter Archive An outstanding collection of recent frame relay topics covered by the twice-weekly Frame Relay Newsletter, authored by frame relay industry experts Steven Taylor and Joanie Wexler. We highly recommend that you subscribe to this twice-weekly newsletter to receive up-to-the-minute frame relay information. Scan Technologies Frame Relay Tutorial Scan Technologies is now hosting the famous "Norm Al Dude and Professor N. Erd" frame relay tutorial and its very well presented visual diagrams. Voice Over Frame Relay Integration Tutorial MICOM authored an extremely thorough tutorial on VoFR Integration. Additionally, check out their Frame Relay Glossary. Frame Relay and Voice Tutorial Intel's Level One division has a thorough VoFR Tutorial that explores "Plain Old Telephone Service" to "DLCI Bandwidth" to "Signaling Functions," bookmark it as a must visit. Good tutorial providing basic information to understand frame relay and its benefits. Presented in question and answer format with frequent diagrams for visual comprehension, courtesy of multicast solutions provider, Starburst Communications. Frame Relay Clears The Hurdles TTC has written an excellent "four part" tutorial with descriptive diagrams. Label Switching On Frame Relay Networks An Internet Engineering Task Force (IETF) 25 page draft that defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in (ARCH) and the Label Distribution Protocol (LDP) described in (LDP) relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs). Cisco competently teaches frame format, frame relay addressing, LMI message format and global addressing. While at times limiting, Cisco manages to provide a useful frame relay tutorial. Cisco hits a "home run" with this excellent tutorial on frame relay design, a must read. Cisco SVCs, ATM and Frame Relay Cisco shows how with a co-located Extended Services Processor (ESP), the Cisco BPX Service Node adds the capability to support ATM and Frame Relay Switched Virtual Circuits (SVCs) in addition to support for Permanent Virtual Circuits (PVCs). Cisco IPX Frame Relay Connections This comprehensive Cisco tutorial is for users who wish to have an in-depth knowledge of network frame relay connections and related functions and who wish to know more about the Port Concentrator Shelf (PCS) which extends the port capacity of an FRP on an IPX or of an FRM on an IGX from 4 high-speed ports to 44 low-speed ports. Cisco introduces the various protocols and technologies used in wide area network (WAN) environments. Topics summarized include point-to-point links, circuit switching, packet switching, virtual circuits, dial-up services and WAN devices. A good starting point for the beginner. Frame Relay Encoding, Encapsulation, Framing and Management Methods Joel Weinberger of International Network Services (which is merging with Lucent), provides a technical overview of frame relay and the various configuration options for data encoding, encapsulation, framing, and link management. Constructing Scalable Frame Relay Networks with OSPF (PDF) International Network Services, (which is merging with Lucent), provides yet another unique 23 page (PDF) document tutorial with outstanding visual diagrams. Cisco, has put together a VERY "heavy duty" web page on configuring Voice Over IP, includes VoIP with Frame Relay Encapsulation. Voice Design and Implementation Guide Cisco tackles Voice Over Frame Relay (VoFR) with a complete guide that is incredibly comprehensive. Worcester Polytechnic Institute's Frame Relay Tutorial John Petrangelo of WPI's Department of Electrical and Computer Engineering has prepared a frame relay tutorial with visual graphics similar to an actual classroom blackboard. A truly unique presentation coupled with good content. Michael Coates Frame Relay Discussion A Network Systems Engineer employed at Clear Communications of New Zealand, Michael Coates, has authored a unique tutorial on frame relay. Michael provides excellent coverage with good visual diagrams of frame relay congestion control, class of service, LMI, frame format, terms, X.25 vs. frame relay and the evolution of frame relay. Frame Relay Networks - A Survey Viswanath Subramanian of the Computer and Information Science Department at Ohio State University wrote this "timeless" tutorial back in the summer of 1995. SNA Over Frame Relay Tutorial (Registration Required) Once more, TechGuide.Com delivers an outstanding tutorial, this time on the subject of SNA over Frame Relay (registration required). With strong visual diagrams this tutorial is highly recommended. Cisco weighs in with a "meaty" tutorial full of outstanding visual diagrams accompanied by easily understood content, an excellent read. Emerging Technologies has assembled a short list of very important frame relay questions. We highly recommended this glossary for understanding "frame relay terms," courtesy of the Frame Relay Forum. Babel's Glossary of Abbreviations and Acronyms Got an abbreviation troubling you because you don't understand what it means? Problem solved, visit this excellent resource. Thank you Irving and Richard Kind. Communications Standards Review which publishes technical reports on multimedia and wireline access technologies provides this very good resource for acronyms. Motorola's Frame Relay Resources Page Motorola has the most famous and extensive frame relay resource available anywhere. Thomas Porter's outstanding website for frame relay information also has "top notch" links to CGI, HTML, Java, JavaScript, Networking, Perl, SNMP, UNIX, Virtual Private Networks, Visual Basic, Windows NT, and Windows 95/98 resources. Frame Relay Fast Packet Switching Tutorial Sangoma Technologies developed this "short but sweet" tutorial that covers virtual circuits, data integrity, flow control/information rates and status polling. Russell Straayer does a great job covering the various topics of Frame Relay Technology in a concise manner, hosted by the Data Comm for Business website. A Tutorial of the Frame Relay Protocol Explains why frame relay is probably the simplest data communications protocol ever conceived. A no frills and just the facts tutorial written all the way back in 1992 and hosted on the General Signal Networks (now INRANGE Technologies Corporation) website. The Protocol Directory provides the reader with an excellent information source for learning about protocols such as frame relay. Ascend Communications has developed this unique resource that provides visual diagrams not only on frame relay but many other networking subjects as well, highly recommended. Frame Relay Forum's Module Presentations "HTML" technical briefs as well as tutorial frame relay presentations offered in "Postscript, Acrobat and Powerpoint Formats." Recommended for those needing frame relay teaching material. Courtesy of the Frame Relay Forum, an organization comprised of vendors, carriers, users and consultants who are committed to successful frame relay deployment. The International Engineering Consortium and Telogy Networks sponsor this tutorial describing the embedded software approach to the voice over frame relay phenomenon. Cisco Frame Relay to ATM Tutorial Cisco hits another "home run" with a fabulous tutorial that is complete with terrific visual diagrams describing frame relay to ATM interworking which enables frame relay traffic to be connected across high-speed ATM trunks using ATM standard Network and Service Interworking. Dave, Ed, Jack, Joe, Marty, Matt and Rob at the SUNY Institute of Technology Utica/Rome have authored a very good analysis of ATM vs. Frame Relay. Unfortunately for potential packet voice users, there are few tutorials on packet voice concepts and benefits targeted at business-level consumers of telephone services. Thus, in this primer, Cisco Systems remedies that condition with a "no-nonsense" exploration of packet voice technology. Data Communications Magazine covers the "hot topic" in networking today, ATM and Frame Relay. Learn how to get the best of both technologies, like running Frame across an ATM backbone or connecting Frame Relay and ATM networks directly. IBM has created an "HTML" masterpiece dedicated to helping you learn about frame relay. Recommended for those seeking a "complete and thorough" understanding of frame relay's "nuts, bolts and internal plumbing." Diagrams compliment every paragraph allowing you to visualize what you read. Many thanks to authors Brian Dorling, Piet Pieters and Elmer J. Valenzuela of IBM for providing a marvelous learning experience, we are extremely grateful to them. AT&T's Frame Relay Tutorial (Registration Required) AT&T and TechGuide.Com provide a road map for frame relay service in the enterprise network environment. The writers and producers at techguide have done a superb job for AT&T in developing this tutorial (registration required). Additionally, check out AT&T's IP Backbone Map, courtesy of Boardwatch Magazine. Furthermore, AT&T has a superb presentation: Optimizing Frame Relay Service Performance and the unique white paper High Speed Packet Services. Voice Over IP Tutorial (Registration Required) Telogy Networks and TechGuide.Com have written perhaps the most outstanding tutorial on VoIP Technology (registration required). How To Launch An International WAN Network Computing's Chris Lewis has written the best document we have seen on creating an International WAN. With the visual diagram information on the second page it is a must read. Pacific Bell authored this famous ISDN Tutorial. The stunning visual diagrams alone are worth visiting, however, when combined with comprehensive technical explanations, it becomes a must visit. The best we have ever seen. VPN Tutorial (Registration Required) Shiva and TechGuide.Com examine the technical, administrative, and organizational factors that dictate which combination of direct dial and VPN components will produce the optimum return on remote access investment (registration required). It also addresses the important questions you should consider before implementing VPN technology as part of a remote access solution while simultaneously outlining the steps necessary for optimizing a remote access solution using VPN technology. Virtual Private Networks Resource Guide (PDF) Ascend Communications has written this 64 page (PDF) document on virtual private networks that in our opinion is one of the finest available anywhere on VPNs. The visual diagrams alone are staggering and the comprehensive coverage of VPNs make this a must read. Cisco tackles the subject of IP Security IPSec Encryption with this comprehensive guide. As one of the original founders of the ATM Forum in 1991, Cisco has one of the best ATM Tutorials. ATM subject areas covered include ATM background, cell header formats, reference models, addressing, switching, connection types and services, quality of service and signaling. Cisco succeeds in providing a very comprehensive glossary of ATM acronyms and abbreviations. The Information Technology Professional's Resource Center Irwin Lazar has created one of the best resources on the net for information technology. Irwin's website covers Data Link Layer (ATM, DSL, Frame Relay), Directory Services, Internet, IP Routing, IP Multicast, IT Publications, Job Sites, Network Management, Network Security, Operating Systems, Physical Layer, QoS and DEN, TCP/IP, Training/Certification, Tutorials and Guides, Virtual Private Networks, Voice and Data Integration, Wireless, Year 2000, and because it is updated frequently, a must visit. Saint Roche Tree Frame Relay Links Here you will find a growing collection of links to frame relay information. In addition, you will find a growing list of links to other networking related topics too. Telecommunications: An Operational Overview Georgia Tech's Stephen Eley does a great job helping you understand telecommunications with this easy to read tutorial that helps put "all the pieces together." Tel-Aviv University put together a great X.25 Tutorial that is currently available on a Russian website. This unique X.25 Tutorial offers superb visual diagrams and is highly recommended. Comparison of IP-over-SONET and IP-over-ATM Technologies Trillium Digital Systems, Inc. provides the most comprehensive discussion we have seen on this subject, highly recommended. Sprint SONET Tutorial (Registration Required) Sprint and TechGuide.Com have written a truly superb SONET Tutorial with excellent visual diagrams and interesting content that makes learning easier (registration required). Nortel goes all out with this 68 page (PDF) tutorial on the Synchronous Optical Network (SONET) standard. Impressive visual diagrams make this a very good learning experience. Introduction to SONET Networking (PDF) 44 page (PDF) document that is a tutorial handbook of advanced SONET networking concepts by Nortel with frequent and outstanding visual diagrams to support excellent content that describes this exciting transport technology. Inverse Multiplexing Tutorial (Registration Required) Larscom and TechGuide.Com examine the factors that make inverse multiplexing a major technology in today's internetworking environment (registration required). This tutorial details those factors, discuss the advantages of inverse muxing solutions, and shows the place of inverse muxing in an evolutionary broadband strategy. All You Wanted To Know About T1 But Were Afraid To Ask Hosted by Data Comm for Business and authored by Bob Wachtel, this is the best tutorial we have found covering the subject of T1s. Minneapolis based Daryl Banttari's TCP/IP Primer is a great starting point for someone who has an interest in TCP/IP, but doesn't know where to start or what questions to ask. With Daryl's TCP/IP Primer you can get beyond the theory and into the "big picture." Boardwatch Magazine presents a spellbinding tutorial on a subject dear to all, Internet Architecture, absolutely a must read. The author, Jack Rickard, is one of the Internet's most well known figures. The ADSL Forum has authored an extremely helpful tutorial about Very high rate Digital Subscriber Line (VDSL) Technology. In simple terms, VDSL transmits high speed data over short reaches of twisted-pair copper telephone lines, with a range of speeds depending upon actual line length. The maximum downstream rate under consideration is between 51 and 55 Mbps over lines up to 1000 ft (300 meters) in length. Downstream speeds as low as 13 Mbps over lengths beyond 4000 ft (1500 meters) are also in the picture. Additionally, you may find VDSL FAQs helpful. xDSL Tutorial for the End-User Randy Day has written a fabulous synopsis (with great visual diagrams) for the end-user who is thinking of using xDSL technology for networking access and needs some practical information. We highly recommend Randy's page for its focus on the needs of an end-user desiring xDSL access. Employing fabulous visual diagrams, the International Engineering Consortium authored this superb xDSL Tutorial that covers existing OSP, prequalification, load coils, bridge taps, loop length, and noise for network operators employing xDSL. xDSL Local Loop Access Technology 3Com does a great job presenting the "Local Loop" aspect of xDSL Technology and describes the different xDSL technologies in development today and compares them to other current and emerging WAN service technologies. It also reports on current and future worldwide xDSL deployments and gives some market introduction projections. Understanding xDSL Performance and Deployability (PDF) Dr. George Zimmerman, Chief Scientist, PairGain Technologies, provides the reader with a thorough understanding of xDSL performance and deployability by using xDSL Spectral Compatibility. This 8 page tutorial in (PDF) format is highly recommended as it employs great visual diagrams. Paradyne, a DSL technology pioneer and innovator, provides the industry's best tutorial. Become a DSL expert immediately, also available for printing in the PDF Version. xDSL Technology Tutorial (PDF) Visually stunning 24 page xDSL Tutorial written by Dr. George Zimmerman, Chief Scientist, PairGain Technologies. You may also wish to take advantage of the PairGain Glossary of xDSL technical terms. Once more Dr. George Zimmerman, Chief Scientist, PairGain Technologies provides the reader with a thorough understanding, this time about OPTIS HDSL2 in this 12 page (PDF) format tutorial. The ADSL Forum describes how Asymmetric Digital Subscriber Line (ADSL), a new modem technology, converts existing twisted-pair telephone lines into access paths for multimedia and high speed data communications. ADSL transmits more than 6 Mbps (optionally up to 8 Mbps) to a subscriber, and as much as 640 kbps (optionally up to 1 Mbps) more in both directions. Furthermore, you may find ADSL Technical FAQs and ADSL FAQs helpful. The ADSL Forum offers a merely "adequate" glossary (molding with age). However, it can be useful. Cisco created one of the great "Internetworking Technology Tutorials" of all time. From routing basics, components and algorithms all the way to ATM, Cisco provides a superb learning experience. Cisco Internetwork Design Tutorials Cisco steps to the plate again with a fabulous collection of internetwork design tutorials. If designing ISDN, ATM and Switched LAN Internetworks is your goal, this is the place to start. Cisco Windows NT Firewall Tutorial Cisco's intended audience for this tutorial are network administrators who want to understand the basic concepts behind the design and deployment of a Windows NT Firewall, the Cisco Centri Firewall. In addition, this tutorial can assist those professionals who are evaluating network security solutions and want to understand how the Cisco Centri Firewall product family distinguishes itself from other Windows NT Firewall solutions, how it works, and how it should be used. Data Communications Magazine Tech Tutorials Here you will find over 85 excellent tutorials on ATM, Cabling, Clustering, High-Speed Networking, IP, Middleware, Network Design, Network Management, Security, Software, Standards and WANs / Remote Access. Web66 Network Construction Set Tutorial Stephen E. Collins of the University of Minnesota wrote this very basic tutorial on LAN/WAN construction, recommended for its simplicity and visual diagrams. Scan Technologies ATM Tutorial Scan Technologies hosts the famous "Norm Al Dude and Professor N. Erd" ATM tutorial and its visually stunning diagrams. Xylan has created a unique switching technology learning experience. This is an excellent read for those interested in exploring what has become an important component of infrastructure technologies. HP OpenView Self-Study Guide (PDF) Hewlett-Packard's 139 page (PDF) document that helps you learn HP OpenView on your own time. The Internet Engineering Task Force (IETF) always has useful information such as the Frame Relay Service MIB, recommended Primers and Tutorials Frame relay Frame Relay Glossary Frame relay primer Frame relay FAQs Frame relay FAQs IBM Frame Relay Guide Frame Relay Tutorial Frame Relay Tutorial A basic guide to frame relay networking Frame Relay Tutorial Frame Relay Frame Relay Fast Packet Switching Frame Relay And IP VPNs: Compete or Coexist? The Expert Guide on Frame Relay Security For Financial Applications Disaster Recovery for Frame Relay Networks Frame relay: handling congestion How to Choose a Service Provider for Frame Relay or ATM Services Frame relay not just for carriers anymore Configuring and Troubleshooting Frame Relay Configuring Frame Relay Frame Relay and Frame-Based ATM: A Comparison of Technologies Megasites and Links Frame Relay Forum Frame Relay, IP, ATM Resource Center Frame Relay Resource Directory Frame Relay Tutorials Frame Relay, VoIP, Providers & Switches Frame Relay Technologies Frame Relay Resources Managing frame relay Frame relay resources SNA Introduction to SNA SNA over Frame Relay (PDF). SNA@enterprise.intranet SNA Technical Overview IBM Systems Network Architecture (SNA) Protocols Frame relay finds respect in SNA circles What to do with that SNA net SNA Features and General IBM/SNA Tips Correlation and Control for the Integrated SNA and TCP/IP Network Advanced Peer-to-Peer Networking (APPN) Implementers Workshop Inside APPN and HPR - The Essential Guide to New SNA SNA & TCP/IP Testing and Networking Information SNA Training SNA Server 4.0 Service Pack 2 Standards Frame Relay Working Group Voice over Frame Relay Voice over frame relay audio primer Voice over frame relay primer Dispelling the myths of voice over frame relay Voice and data over frame relay Convergence? Try voice over frame Voice over frame relay: Is free too expensive?Network World Fusion Focus on Frame Relay, 08/04/99. Frame Relay and Voice Tutorial Voice over Frame Relay Multimedia Switching Voice Over Frame Relay Integration A list of service prodviders -- Worldwide, USA, Europe, etc. A list of frame relay service providers AT&T Frame Relay and ATM Services Bell Atlantic frame relay services FrameStream Frame Relay - Case Studies Case in point: Florida Informanagement Case Study: Firm Streamlines With Frame Relay Symplex Case Studies Case Studies: Sync Research Solutions at Perle Positioning frame relay Match Frame Relay bandwidth to your application needs A.P. Green Saves Big by Migrating SNA to Frame Relay Oil Company Pumps Savings With Integrated Frame Relay Network New Network Carries Voice, Fax, Data and LAN Traffic Over Public Frame Relay ACTnet Makes Public Frame Relay Networking Pay Off In Savings Frame relay in the library Network World Fusion Focus on Frame Relay Press releases/newsletters ComputerHelp.Net: Frame Relay Discussion Forum Frame Relay Discussion Forum Network World articles on frame relay Recent Network World articles about frame relay
|
This web site is Copyrighted (c) 1998 - 2006 - All Rights Reserved
450,000 people visit here each month ... Originate - Don't Duplicate. They are watching
Variable-length packets ){kind=link}