It's a relatively inexpensive technology though alternative structures like virtual private networks VPNs or multiprotocol label switching MPLS are often preferred. What it does not provide is correction and end-to-end recovery of data. These functions must be available in the applications that use the protocol to transport information.
Frame relay protocol is modeled after packet-switched technologies much like x. There are essentially two flavors of this protocol.
One is based on Q. The other conforms to LMI specifications and is used less frequently. The discard eligibility DE bit is set by the DTE to tell the Frame Relay network that a frame has lower importance than other frames and should be discarded before other frames if the network becomes short of resources. Thus, it represents a very simple priority mechanism. This bit is usually set only when the network is congested. The previous section described the basic Frame Relay protocol format for carrying user data frames.
The LMI message format is shown in Figure In LMI messages, the basic protocol header is the same as in normal data frames. The actual LMI message begins with 4 mandatory bytes, followed by a variable number of information elements IEs. The next byte is referred to as the protocol discriminator , which is set to a value that indicates LMI.
The third mandatory byte the call reference is always filled with zeros. The final mandatory byte is the Message Type field. Two message types have been defined. Status-enquiry messages allow the user device to inquire about network status. Status messages respond to status-enquiry messages. Keepalives messages sent through a connection to ensure that both sides will continue to regard the connection as active and PVC status messages are examples of these messages and are the common LMI features that are expected to be a part of every implementation that conforms to the consortium specification.
Together, status and status-enquiry messages help verify the integrity of logical and physical links. This information is critical in a routing environment because routing algorithms make decisions based on link integrity. Following the Message Type field is some number of IEs. In addition to the common LMI features, several optional LMI extensions are extremely useful in an internetworking environment.
The first important optional LMI extension is global addressing. In this case, no addresses identify network interfaces or nodes attached to these interfaces. Because these addresses do not exist, they cannot be discovered by traditional address resolution and discovery techniques. This means that with normal Frame Relay addressing, static maps must be created to tell routers which DLCIs to use to find a remote device and its associated internetwork address.
The global addressing extension permits node identifiers. With this extension, the values inserted in the DLCI field of a frame are globally significant addresses of individual end-user devices for example, routers. This is implemented as shown in Figure In Figure , note that each interface has its own identifier.
Suppose that Pittsburgh must send a frame to San Jose. At the exit point, the DLCI field contents are changed by the network to 13 to reflect the source node of the frame. Each router interface has a distinct value as its node identifier, so individual devices can be distinguished.
This permits adaptive routing in complex environments. Global addressing provides significant benefits in a large, complex internetwork. No changes to higher-layer protocols are needed to take full advantage of their capabilities. Multicasting is another valuable optional LMI feature. Multicast groups are designated by a series of four reserved DLCI values to Frames sent by a device using one of these reserved DLCIs are replicated by the network and sent to all exit points in the designated set.
The multicasting extension also defines LMI messages that notify user devices of the addition, deletion, and presence of multicast groups. In networks that take advantage of dynamic routing, routing information must be exchanged among many routers.
Routing messages can be sent efficiently by using frames with a multicast DLCI. This allows messages to be sent to specific groups of routers. Another important setting to consider when looking at Frame Relay networks is the initial encapsulation type used when the protocol is activated on an interface.
This setting must be consistent between end devices on the internetwork. If you are connecting Cisco-only devices, Cisco encapsulation may be used. This is the default encapsulation type on Cisco routers. If you are connecting to hardware from other vendors, IETF encapsulation should be used.
Frame Relay can be used as an interface to either a publicly available carrier-provided service or to a network of privately owned equipment. Figure shows this configuration. A public Frame Relay service is deployed by putting Frame Relay switching equipment in the central offices of a telecommunications carrier. In this case, users can realize economic benefits from traffic-sensitive charging rates and are relieved from the work necessary to administer and maintain the network equipment and service.
In either type of network, the lines that connect user devices to the network equipment can operate at a speed selected from a broad range of data rates. Speeds between 56 kbps and 2 Mbps are typical, although Frame Relay can support lower and higher speeds.
Whether in a public or private network, the support of Frame Relay interfaces to user devices does not necessarily dictate that the Frame Relay protocol is used between the network devices.
No standards for interconnecting equipment inside a Frame Relay network currently exist. Thus, traditional circuit-switching, packet-switching, or a hybrid approach combining these technologies can be used. This section discusses troubleshooting procedures for connectivity problems related to Frame Relay links. It describes specific Frame Relay symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.
The following sections cover the most common network issues in Frame Relay networks:. Symptom : Connections over a Frame Relay link fail. The output of the show interfaces serial exec command shows that the interface and line protocol are down, or that the interface is up and the line protocol is down. Table outlines the problems that might cause this symptom and describes solutions to those problems. Use the show interfaces serial command to see whether the interface and line protocol are up.
If the interface and line protocol are down, check the cable to make sure that it is a DTE 1 serial cable.
Make sure that cables are securely attached. This should be negligible for short distances, but it adds up over long distances. A rule of thumb is that for every 1, circuit miles, expect 20ms of latency. Frame Relay is available in any combination of fractional DS1 rates. In every packet-switched network, including Frame Relay, each packet must know its source and destination addresses.
This information is used to route the frames within the telecom network. Another use of the DLCI is to differentiate between virtual connections on the same physical port. Packets for several different virtual ports are statistically multiplexed onto the physical port to be transmitted. The aggregated logical connections can coexist on a single physical port because it's the DLCI that logically binds the data to the connection. If you've been paying attention thus far, you know that in a Frame Relay architecture, you have a physical dedicated circuit between your CPE and the telecom's network switch.
The same configuration exists at your ISP's location. Because between those two network switches the data is packet-switched, there is no guarantee that the path the data travels is consistent. This is why Frame Relay networks are generally represented by a cloud in diagrams. In reality, the data generally travels the same path; it would travel different routes only if there were significant amounts of congestion or hardware failure.
The path between the telecom switches is commonly referred to as a virtual circuit. This is an apt description because there is no actual dedicated circuit, and your data can travel over many physical paths and switches. Because variety is the spice of life, there is, of course, a choice of virtual circuits.
The switched virtual circuit SVC is constructed when there is a need to pass data. After some defined threshold has been reached such as no traffic for the past 30 seconds , the virtual circuit is torn down.
This acts in many respects like the normal analog phone system. The circuit is always available and always connected. It's fast, but the problem is that you're paying for each of these lines. An extremely useful application of PVCs can be demonstrated when you want to connect multiple sites together directly but cost-effectively. Frame Relay does not have to be deployed in strictly a point-to-multipoint configuration.
There are several applications of deploying a mesh of PVCs between remote locations, providing multiple virtual paths and direct routes between remote locations without having to first travel through your ISP's router. You have to pay for each PVC defined through the Frame Relay network, but the performance trade-off might be worth the additional expense. Figure 5 shows an example of a mesh of PVCs. Figure 5 In a switched virtual circuit, numerous connections exist within the mesh; they are created and destroyed as necessary.
The second major difference between Frame Relay and dedicated point-to-point circuits is how the circuit capacity is described. Dedicated point-to-point circuits are just that: dedicated. If you send no data, the channel time slots are still allocated to your circuit. Remember that Frame Relay is a shared network using packet-switched technology. The intent is to use the full capacity of the circuits, whether or not you're transmitting any data. Therefore, in a shared environment, there needs to be some provision to make sure that you get what you're paying for.
The physical port speed is the absolute maximum data rate accepted by the Frame Relay network provider. The port speed is generally twice that of the CIR. HDLC is a synchronous protocol, meaning that it is synchronized to a clock source. When data is transmitted, the whole frame is transmitted at the clock speed, thus bursting over CIR because there is no way to slow down the data.
The difference between the guaranteed CIR and the port speed is available on a best-effort-only basis. The Local Management Interface LMI is a keep-alive mechanism to periodically check to make sure that the interface is still active. Additionally, it is used to give the end user circuit status information such as whether the link is congested.
As with practically all standards, the three versions of LMI are not interoperable. LMI is fairly ubiquitous. Most vendors support Annex D, although very few vendors support Annex A.
Delay and congestion are a direct result of the shared nature of packet network resources. Each piece of the packet-switched data network introduces delays because of the processing that occurs at each node to determine the next hop for the packet. Delay is synonymous with latency , which is the time required for transmission from origin to destination. Latency is usually measured in milliseconds. The threshold for delay interval intolerance for humans is roughly ms.
Delay is not a problem in circuit-switched networks because each call uses a reserved circuit. Congestion exists in circuit-switched networks only when all available timeslots are used.
You might be familiar with the phrase "All circuits are busy. Shared packet-switched networks are much more dynamic and bursty. Frame Relay networks aggregate multiple PVCs onto a single physical circuit. When there is more aggregated data in the network than there is bandwidth, you have congestion. This is similar to merging five lanes of traffic into two lanes over a bridge. This normally doesn't cause a problem for 20 hours a day, but during rush hour it seems to have an effect on people's blood pressure.
The Frame Relay Forum has defined several mechanisms to handle the congestion problem. Several bits are defined in the Frame Relay header that allow network switches to notify other switches or Frame Relay end nodes of impending congestion see Figure 6. Figure 6 Part of the Frame Relay header deals with congestion.
0コメント