THE BASIC GUIDE TO
|
| Table of Contents | Basic Guide Title Pages |
|
|
Chapter Two |
In this chapter, we will discuss in more detail how frame relay works. We'll concentrate on the basic flow of data within a frame relay network.
Basic Trail: Go!
The basic trail will give begin with an overview of virtual circuits. Next, we'll show you the frame relay frame, how it's constructed and how it moves across the frame relay network. Finally, on the Basic Trail, we'll introduce the concept of discarding frames.
Advanced Trail: Go!
If you take the advanced trail, you'll find a comparison of X.25 and frame relay processing and a more detailed discussion of error recovery by higher layer protocols.
View Points :
Figure 3: Basic frame structure of popular synchronous protocols Go
Figure 4: Frame structure and header of frame relay frame Go
Figure 5: DLCI path through the network Go
Figure 6: X.25 versus frame relay processing flow chart Go
Shortcut: Go!
The shortcut summarizes the basic flow of data in a frame relay network.
Virtual Circuits in Frame Relay
Frame relay technology is based on the concept of using virtual circuits (VCs), which are two-way, software-defined data paths between two ports that act as private line replacements in the network. While today there are two types of frame relay connections, switched virtual circuits (SVCs) and permanent virtual circuits (PVCs), PVCs were the original service offering. As a result, PVCs were more commonly used, but SVC products and services are growing in popularity. A more detailed discussion of SVCs and their benefits occurs in Chapter 3. For now, let's discuss the basic differences between PVCs and SVCs.
Using PVCs
PVCs are set up by a network operator — whether a private network or a service provider — via a network management system. PVCs are initially defined as a connection between two sites or endpoints. When a site is connected to the network, new PVCs may be added when there is a demand for new sites, additional bandwidth, alternate routing, or when new applications require existing ports to talk to one another.
PVCs are fixed paths, not available on demand or on a call-by-call basis. Although the actual path taken through the network may vary from time to time, such as when automatic rerouting takes place, the beginning and end of the circuit will not change. In this way, the PVC is like a dedicated point-to-point circuit.
PVCs are popular because they provide a cost-effective alternative to leased lines. Provisioning PVCs requires thorough planning, a knowledge of traffic patterns, and bandwidth utilization. There are fixed lead times for installation which limit the flexibility of adding service when required for short usage periods.
Using SVCs
Switched Virtual Circuits (SVCs) are available on a call-by-call basis. Establishing a call by using the SVC signaling protocol (Q.933) is comparable to normal telephone use. Users specify a destination address similar to a phone number.
Implementing SVCs in the network is more complex than using PVCs, but is transparent to end users. First, the network must dynamically establish connections based on requests by many users (as opposed to PVCs where a central network operator configures the network). The network must quickly establish the connection and allocate bandwidth based on the user's requests. Finally, the network must track the calls and bill according to the amount of service provided.
Although SVCs were defined in the initial frame relay specifications, they were not implemented by the first carriers or vendors of frame relay. Today, applications well-suited to SVCs are driving its deployment. While PVCs offer the statistical bandwidth gain of frame relay, SVCs deliver the any-to-any connectivity that can result in network savings and flexibility. (See Chapter 3 for a more complete discussion of SVC applications and benefits.)
The frame relay header and DLCI
Now that we know about virtual circuits, and the fundamental differences between PVCs and SVCs, let's take a look at the basic structure of a frame relay frame and how it accommodates other technologies.
In the most popular synchronous protocols, data is carried across a communications line in frames which are similar in structure, as shown in Figure 3.
Figure 3: Basic frame structure for several popular
synchronous communications protocols.
In a frame relay frame, user data packets are not changed in any way. Frame relay simply adds a two-byte header to the frame. Figure 4 shows the frame relay frame structure and its header in more detail.
Figure 4: Frame structure and header format for frame relay
For now, let's look at the largest portion of the header, the DLCI. The remaining six bits of the frame relay header are discussed in the next chapter.
The frame relay header contains a 10-bit number, called the Data Link Connection Identifier (DLCI). The DLCI is the frame relay virtual circuit number (with local significance) which corresponds to a particular destination. (In the case of LAN-WAN internetworking, the DLCI denotes the port to which the destination LAN is attached.) As shown in Figure 5, the routing tables at each intervening frame relay switch in the private or carrier frame relay network route the frames to the proper destination.
Note: In the figures illustrating frame relay networks, the user devices are often shown as LAN routers, since this is a common frame relay application. They could also be LAN bridges, hosts, front end processors, FRADs or any other device with a frame relay interface.
Figure 5: The DLCI denotes the port on which the destination is located
The DLCI allows data coming into a frame relay switch (often called a node) to be sent across the network using a simple, three-step process, which is shown as a flow chart in Figure 6 in this chapter.
1. Check the integrity of the frame using the Frame Check Sequence (FCS) — if it indicates an error, discard the frame.
2. Look up the DLCI in a table — if the DLCI is not defined for this link, discard the frame.
3. Relay the frame toward its destination by sending it out the port or trunk specified in the table.
Simple Rule: If there is a problem, discard the data
In order to simplify frame relay as much as possible, one simple rule exists: if there is any problem with a frame, simply discard it. There are two principal reasons why frame relay data might be discarded:
But how can the network discard frames without destroying the integrity of the communications? The answer lies in the existence of intelligence in the endpoint devices, such as PCs, workstations, and hosts. These endpoint devices operate with multilevel protocols which detect and recover from loss of data in the network. Incidentally, this concept of using intelligent upper layer protocols to make up for a backbone network is not a new idea. The Internet relies on this method to assure reliable communication across the network.
If you're interested in a more detailed discussion of how the upper layer protocols recover from the loss of a frame and the causes of discarded frames, continue on to the advanced trail.
If you prefer to go right to Chapter 3, you'll find a discussion of how the frame relay network handles congestion and frame discards.
Processing: Frame Relay Versus X.25
The frame relay node processes data in a relatively simple manner compared to more fully-featured protocols like X.25. Figure 6 contrasts the simplicity of frame relay with the more complex processing of X.25. (For the sake of simplicity, the diagram reflects the path of a valid data packet. Showing the steps for error recovery and non-information frame processing for X.25 would make it much more complicated.)
Figure 6: Simplified model of X.25 and frame relay processing
Recovery by Higher Layer Protocol
As you can see in Figure 6, frame relay technology simplifies the processing task, and it relies on the endpoint devices to compensate for frame loss.
How does an upper layer protocol recover from the loss of a frame? It keeps track of the sequence numbers of the various frames it sends and receives. Acknowledgments are sent to let the sending end know which frame numbers have been successfully received. If a sequence number is missing (after waiting for a "time-out" period), the receiving end will request a retransmittal.
In this manner, the two end devices ensure that all of the frames eventually are received without errors. This function occurs at Layer 4, the Transport Layer, in protocols like TCP/IP and OSI Transport Class 4. By contrast, X.25 networks perform this function at Layers 2 and 3, and the endpoints need not duplicate the function in Layer 4.
While the higher layers will reliably recover from frame discards, end-to-end recovery is costly. A single lost frame will result in retransmitting all unacknowledged frames. Such recovery takes extra cycles and memory in the endpoint computers, and it uses extra network bandwidth to retransmit multiple frames. Worst of all — it causes large delays due to the higher layer time-outs (the time spent waiting for the frame to arrive before declaring it lost) and the time spent retransmitting.
Even though the higher layers can recover when discards occur, a major factor in the overall performance of a network is the ability of the network to minimize frame discards.
Two causes of frame discards are bit errors and congestion.
Frame Discards Caused by Bit Errors
When an error occurs in a frame, typically caused by noise on the line, it is detected upon receipt of the frame using the Frame Check Sequence (FCS). See Figure 4.
Unlike X.25, the frame relay node detecting the error does not request the sender to correct the error by retransmitting the frame. The node simply throws the frame away and moves on to receive the next frame. It relies on the intelligence of the PC or workstation that originated the data to recognize that an error has occurred and to resend the frame. Because the cost of having the higher layers recover is great, this approach would have a disastrous effect on network efficiency if the lines are noisy, generating many errors.
Fortunately, most backbone lines are based on fiber optics and experience extremely low error rates. This lowers the frequency of error-induced endpoint data recovery on lines and effectively eliminates the problem. Thus, frame relay is useful with clean, digital lines that have low error rates, while X.25 may be required for good performance on lines with higher error rates.
Frame Discards Caused by Congestion
Network congestion occurs for two reasons. First, a network node receives more frames than it can process. This is called receiver congestion. Second, a network node needs to send more frames across a given line than the speed of the line permits, which is called line congestion.
In either case, the node's buffers (temporary memory for incoming frames awaiting processing or outgoing frames lining up to be sent) are filled and the node must discard frames until the buffers have room.
Since LAN traffic is extremely bursty, the probability of congestion occurring occasionally is high unless, of course, the user excessively overconfigures both the lines and the switches — and thereby overpays on network costs. As a result, it is very important that the frame relay network have excellent congestion management features both to minimize the occurrence and severity of congestion and to minimize the effect of the discards when they are required. Congestion management features are discussed in more detail in the following chapter.
The basic flow of data in a frame relay network can best be described in a series of key points:
END CHAPTER TWO.
GO TO CHAPTER THREE
