THE BASIC GUIDE TO
|
| Table of Contents | Basic Guide Title Pages |
|
|
Chapter Three |
In this chapter, we'll discuss how frame relay technology handles interface signaling for control. If that sounds too complicated, think of it this way: interface signaling provides information about what is happening on the network so that users can get the response time they expect and the network will have the greatest efficiency possible. Signaling mechanisms can also provide options for building different types of frame relay networks to match your applications and the performance they demand.
Basic Trail: Go!
The basic trail will acquaint you with three types of signaling mechanisms used in frame relay:
Advanced Trail: Go!
If you take the advanced trail, you'll find more information about the Local Management Interface (LMI) specification, which is a connection status mechanism.
View Points :
Figure 7: The importance of congestion management Go
Figure 8: Frame relay frame showing the FECN, BECN and DE bits Go
Figure 9: The use of FECN and BECN in explicit congestion notification Go
Figure 10: PVC Signaling using the LMI specification Go
Shortcut: Go!
The shortcut will quickly cover the three types of congestion management. It will also give highlights of the two other types of interface signaling discussed in the chapter, PVC status and SVC signaling.
The Need for Signaling Mechanisms
When frame relay was first proposed, it was based on a simple rule: keep the network protocol simple and let the higher layer protocols of the end devices worry about the other problems. But upon further study, it became apparent to the standards organizations that practical implementation of frame relay in real-world networks would need to specify signaling mechanisms to address three important issues:
Although these mechanisms add complexity to frame relay, the standards have an important provision which allows basic frame relay to remain simple: the use of signaling mechanisms is optional. That is, a vendor is not required to implement these features.
Without the signaling mechanisms, the resulting frame relay interface would still be compliant with the standard and data will still flow. With the signaling mechanisms, however, the throughput of the network, the response time to users, and the efficiency of line and host usage are improved.
Let's look at how these frame relay signaling mechanisms work.
Congestion Notification Mechanisms
Congestion management mechanisms, like the other signaling mechanisms, are optional for compliance, but they will affect performance. The importance of congestion management is illustrated in Figure 7.
Figure 7: The importance of congestion management
The traffic entering the network is called the "offered load." As the offered load increases, the actual network throughput increases linearly. The beginning of congestion is represented by Point A, when the network cannot keep up with the entering traffic, and begins flow control.
If the entering traffic continues to increase, it reaches a state of severe congestion at Point B, where the actual effective throughput of the network starts to decrease due to the number of retransmissions. This causes a given frame to be sent into the network multiple times before successfully making it through.
In severe congestion, the overall network throughput can diminish, and the only way to recover is for the user devices to reduce their traffic. For that reason, several mechanisms have been developed to notify the user devices that congestion is occurring and that they should reduce their offered load.
The network should be able to detect when it is approaching congestion (Point A) rather than waiting until Point B is reached before notifying the end devices to reduce traffic. Early notification can avoid severe congestion altogether.
The ANSI specifications are very clear about the mechanisms used to indicate the existence of congestion in the network. There are two types of mechanisms to minimize, detect and recover from congestion situations, in effect providing flow control:
Another mechanism that may be employed by end user devices is implicit congestion notification.
These mechanisms use specific bits contained within the header of each frame. The location of these specific bits (FECN, BECN and DE) are shown in Figure 8.
Figure 8: Frame relay frame showing the FECN, BECN and DE bits
Let's look at how each of these mechanisms function.
Explicit Congestion Notification (ECN) Bits
The first mechanism uses two Explicit Congestion Notification (ECN) bits in the frame relay header. They are called the Forward Explicit Congestion Notification (FECN) and the Backward Explicit Congestion Notification (BECN) bits. Figure 9 depicts the use of these bits.
Figure 9: The use of FECN and BECN in explicit congestion notification
Let's suppose Node B is approaching a congestion condition. This could be caused by a temporary peak in traffic coming into the node from various sources or by a peak in the amount of traffic on the link between B and C. Here is how forward congestion notification would occur:
Depending upon the protocols used and the capabilities of the CPE device and the network switches, it is sometimes more useful to notify the source of the traffic that there is congestion, so the source can slow down until congestion subsides. (This assumes that the source is capable of responding to receipt of the congestion notification signals.)
This is how backward congestion notification occurs:
The FECN and BECN process can take place simultaneously on multiple DLCIs in response to congestion on a given line or node, thus notifying multiple sources and destinations. The ECN bits represent an important tool for minimizing serious congestion conditions.
Implicit Congestion Notification
Some upper layer protocols, such as Transport Control Protocol (TCP), operating in the end devices have an implicit form of congestion detection. These protocols can infer that congestion is occurring by an increase in round trip delay or by detection of the loss of a frame, for example. Reliance on network traffic characteristics to indicate congestion is known as implicit congestion notification.
These upper layer protocols were developed to run effectively over networks whose capacity was undetermined. Such protocols limit the rate at which they send traffic onto the network by means of a "window," which allows only a limited number of frames to be sent before an acknowledgment is received.
When it appears that congestion is occurring, the protocol can reduce its window size, which reduces the load on the network. As congestion abates, the window size is gradually increased.
The same window-size adjustment is also the normal way for the end-user devices to respond to explicit congestion notification -- FECN and BECN. The ANSI standards state that implicit and explicit congestion notification are complementary and can be used together for best results.
Discard Eligibility
Frame relay standards state that the user device should reduce its traffic in response to congestion notification. Implementation of the recommended actions by the user device will result in a decrease in the traffic into the network, thereby reducing congestion. If the user device is incapable of responding to the signaling mechanisms, it might simply ignore the congestion signal and continue to transmit data at the same rate as before. This would lead to continued or increased congestion.
In this case, how does the network protect itself? The answer is found in the basic rule of frame relay: if there is a problem, discard the data. Therefore, if congestion causes an overload, more frames will be discarded. This will lengthen response times and reduce overall network throughput, but the network will not fail.
When congestion does occur, the nodes must decide which frames to discard. The simplest approach is to select frames at random. The drawback of this approach is that it maximizes the number of endpoints which must initiate error recovery due to missing frames.
A better method is to predetermine which frames can be discarded. This approach is accomplished through the use of the Committed Information Rate (CIR). The CIR is the average information capacity of the virtual circuit. When you subscribe to or buy a frame relay service from a carrier, you specify a CIR depending on how much information capacity you think your network will need.
In each frame header, there is a bit called the Discard Eligibility (DE) bit (see Figure 8). A DE bit is set to one (1) by the CPE device or the network switch when the frame is above the CIR. When the DE bit is set to l, it makes the frame eligible for discard in response to situations of congestion. A frame with a DE bit of 1 is discarded in advance of non-discard-eligible data (those frames with a DE bit set to zero (0)). When the discard of DE-eligible data, by itself, is not sufficient to relieve severe congestion, additional incoming frames are discarded without regard to the setting of the DE bit.
Status of Connections (PVCs and SVCs)
The next type of optional signaling mechanism defines how the two sides of a frame relay interface (e.g., the network and the router) can communicate with each other about the status of the interface and the various PVCs on that interface.
Again, these are optional parameters. It is possible to implement a frame relay interface and pass data without implementing these parameters. This signaling mechanism simply enables you to retrieve more information about the status of your network connection.
This status information is accomplished through the use of special management frames with a unique DLCI address which may be passed between the network and the access device. These frames monitor the status of the connection and provide the following information:
The connection status mechanism is termed the Local Management Interface (LMI) specification. There are currently three versions of the LMI specification:
|
Protocol
|
Specification
|
|
LMI
|
Frame Relay Forum Implementation Agreement (IA) FRF.1 superceded by FRF.1.1
|
|
Annex D
|
ANSI T1.617
|
|
Annex A
|
ITU Q.933 referenced in FRF.1.1
|
While LMI was used colloquially for the FRF.1 IA, it may also be used as a generic term to refer to any and all of the protocols. The revised Frame Relay Forum IA FRF.1.1 calls for the mandatory implementation of Annex A of ITU Q.933.
Each version includes a slightly different use of the management protocol. Virtually all equipment vendors support LMI and most support Annex D, while Annex A is supported by fewer vendors. To ensure interoperability when your network consists of equipment from different vendors, the same version of management protocol must be at each end of the frame relay link.
For a little history of LMI and more detail on the functions of the different versions, see the advanced trail later in this chapter.
Switched Virtual Circuits
The final signaling mechanism we will discuss is SVC signaling. Unlike the previous two signaling mechanisms discussed — congestion status and connection status — SVC signaling does not offer the network operator information about the network. Rather, SVC signaling specifications allow an alternative to permanent virtual circuits. In turn, SVC signaling must provide call setup and call disconnect. Call setup includes information about the call, such as measuring data sent, acceptance, addresses and bandwidth parameters.
SVCs can also provide opportunities for new applications and new network usage. This section will discuss those alternatives and opportunities.
SVC Implementation Agreement
Implementation Agreement FRF.4 defines the needed messages and procedures to establish an SVC. Basically, the network alerts the requested destination of the incoming call and the destination chooses whether or not to accept it. If the destination accepts, the network builds the SVC across the network switches. Once the network establishes the SVC, the two endpoints can transfer information. When the endpoints no longer need the connection, either one notifies the network to terminate the call.
SVC Benefits
While current provisions for PVCs are adequate for the vast majority of near-term applications, SVC capability is beginning to gain momentum for use in public frame relay networks and for very large private networks. With SVCs, users can request set up of virtual connections only when needed and negotiate throughput rate and burst size depending on the application.
SVC Network Applications
Some of the benefits become clearer as we look at the various applications where SVC technology is well-suited.
Remote Connectivity
At the fringes of the network or in sites where there is little need to contact other locations, SVCs are an excellent way to provide basic connectivity cost effectively. The customer only pays for the use of the network when needed, without requiring PVCs at the user-to-network interface. This application holds a great deal of promise for remote locations accessing high-speed frame relay implementations.
Overflow Traffic
There may be times of the day or night when using the burst capability of the main PVC alone cannot satisfy the need for excess capacity. Since SVCs can be set up on an adhoc basis, they can fulfill the demands of seasonal, sporadic or finite-use traffic and offer true bandwidth on demand.
Intranets and Extranets
These two applications are compelling because they allow frame relay (with SVCs) to access the Internet territory. For customers uncomfortable with the variations in quality of the Internet, building an intranet or extranet using frame relay may be a good alternative. This is a whole new set of services carriers could offer.
Dial Access
To access a frame relay service from a carrier, a "local loop" connects the user premises to the carrier's nearest point-of-presence (POP). This local loop can be either a leased line or a dial line. Users dialing into the frame relay network can connect to either a PVC network or an SVC network.
Disaster Recovery or Alternate Network Paths
For networks using back-up or recovery sites and alternate network paths, SVCs can provide an economical alternative to leased lines, switched services or PVCs. They provide the network flexibility required when leased lines are not available or there is no time to provision PVCs.
The advanced trail will discuss two topics in more depth: the LMI specification and the SVC Implementation Agreement.
In this section, we will refer to the two major standards-setting organizations, the American National Standards Institute (ANSI) and the International Telecommunications Union - Telecomunications Services Sector (ITU-T). For more information on standards, please read Chapter 4.
LMI Specification
As you may recall if you went through the basic trail, there are three versions of the LMI specification. Let's reiterate them here:
|
Protocol
|
Specification
|
|
LMI
|
Frame Relay Forum IA FRF.1 superceded by FRF.1.1
|
|
Annex D
|
ANSI T1.617
|
|
Annex A
|
ITU Q.933 referenced in FRF.1.1
|
The first definition for PVC status signaling was in the LMI specification. The protocol defined for the LMI provides for a "status inquiry" message which the user device (e.g., router) can send, either simply as a "keep alive" message to inform the network that the connection to the router is still up, or as a request for a report on the status of the PVCs on that port.
The network then responds with a "status" message, either in the form of a "keep alive" response or in the form of a full report on the PVCs. (See Figure 10.) An additional optional message, "status update," is also defined which enables the network to provide an unsolicited report of a change in PVC status.
Figure 10: PVC Status Signaling per LMI specification
Notice that the LMI status query only provides for one-way querying and one-way response, meaning that only the user device (e.g., router) can send a "status inquiry" message, and only the network can respond with a "status" message. While this approach was simple to implement, it resulted in some limitations in functions. Using status inquiries in this manner, both sides of the interface are unable to provide the same commands and responses. Most notably, it addressed only the User Network Interface (UNI) and would not work in a Network-to-Network Interface (NNI) due to the one way communications of the interface. UNI provides the end device interface to the network.
NNI provides the ability for networks to query and respond to one another. When only UNIs are available, this could lead to problems within hybrid private/public networks, where a private network node would have a frame relay NNI interface to a public frame relay service.
Therefore, just before final approval of the standard for frame relay signaling, ANSI extended the standard to provide a bi-directional mechanism for PVC status signaling that is symmetric. The bi-directional mechanism provides the ability for both sides of the interface to issue the same queries and responses. This mechanism is contained in Annex D of T1.617, known simply as Annex D. Annex D works in both the UNI and NNI interfaces.
In contrast to the LMI (which uses DLCI 1023), Annex D reserves DLCI 0 for PVC status signaling. The current requirement in FRF.1.1, Annex A signaling, is similar to Annex D and also uses DLCI 0.
To insure interoperability in a multi-vendor network environment, the same version of management protocol must be at each end of the frame relay link.
SVC Implementation Agreement
The SVC Implementation Agreement is based on existing SVC standards in ANSI and ITU-T. The current SVC standards are T1.617 in ANSI and Q.933 in ITU-T. These two documents lay the basis for Q.2931, the standard for access signaling for ATM (Asynchronous Transfer Mode), as well as for the PVC management procedures for frame relay.
The SVC Implementation Agreement can enable expanded service in frame relay networks. Use in internal networks involves implementing SVCs that are internal to a public or private network. The SVCs would remain transparent to the users who maintain their user-to-network interface PVCs, for example, in the case of disaster recovery. Used in wide area networks, SVCs may be used over large geographic areas such as transatlantic applications, which have been traditionally cost-prohibitive.
ISDN and Switched Access for PVCs and SVCs
Access on demand for PVCs and SVCs, whether via Integrated Services Digital Network (ISDN) or switched access is another method to reach the frame relay network. Access on demand holds a great deal of promise for remote locations accessing high-speed frame relay implementations.
In switched access, a circuit-switched connection to the frame relay switch can be established using the existing voice network. An indication is then sent to the switch that a frame relay call is being established; the switch makes the connection and bills the call appropriately. The customer pays only for the use of the local loop when needed, without requiring PVCs at the user-to-network interface. The same benefits are true for ISDN access and E.164 addressing and lead to true, any-to-any connectivity through ISDN or switched access.
Interface signaling mechanisms provide information about the frame relay network so that network operators can improve efficiency. Signaling mechanisms also provide optional ways of configuring your frame relay network to match applications usage.
There are three types of signaling mechanisms used in frame relay:
The ANSI standard defines a method for the network to signal the existence of congestion called the Explicit Congestion Notification (ECN) bits.
Frame relay uses FECN (Forward ECN) and BECN (Backward ECN) bits to notify end user devices about network congestion.
Although the frame relay protocol does not respond to congestion, some higher layer protocols for end user devices may respond to Implicit Congestion Notification by recognizing that end-to-end delays have increased or that frames have been dropped.
The use of the "discard eligibility" (DE) bit can be a powerful tool for managing throughput, including the ability to meter traffic and to guarantee a level of service.
The ANSI and ITU standards define a mechanism for communicating the status of PVCs on a frame relay interface based on a modification of the method in the LMI specification.
SVC signaling allows an alternative to permanent virtual circuits which can improve the efficiency of the network. SVCs can also provide opportunities for new applications and new network usage.
END CHAPTER THREE.
GO TO CHAPTER FOUR
