Committed information rate
From Hill2dot0
The committed information rate (CIR) is a rate associated with a virtual circuit on a frame relay user-to-network interface(UNI) or network-to-network interface (NNI). It provides an indicator of how much traffic the user expects to place on that virtual circuit, and how much capacity the network agrees to provide for that virtual circuit. In other words, it provides an indication of throughput potential.
Contents |
Reasons For Having a CIR
Before looking at the details of the CIR and how they are determined, it is worth taking a small side trip to discuss why they are even used. CIRs were defined for fine technical reasons, but they remain a highly misunderstood concept by customers and vendors alike.
It must first be recognized that CIRs are not an instantaneous measurement, but instead a measure of a quantity of [[bit]s delivered over some amount of time. Thus, a “32 kbps” CIR is precisely stated as “32 kilobits delivered in 1 second.” While this might appear to be a subtlety or nuance, it is an important one because if CIR were actually an instantaneous measurement, users would frequently exceed their CIR while transmitting because the access rate generally exceeds the CIR.
Consider the scenario of getting a speeding ticket. Measuring the speed limit on our roads is an instantaneous measurement. If a police officer clocks you traveling at 60 mph (96 km/h) in a 30 mph (48 km/h) zone, you are speeding. At that instant in time, you were traveling 60 mph (96 km/h). On the other hand, if the speed were measured like CIR as an average quantity over some time period, you could claim to the officer that you were only going to be traveling for half an hour, not the full hour. In effect, you would have traveled thirty miles (48 kilometers) in thirty minutes and zero miles for the remainder of the hour—your average is 30 mph (48 km/h)—still within the limit. Too bad it doesn’t work that way.
In summary, the duration of the measurement interval is quite important. Data traffic, by its nature, is bursty. Therefore, a longer interval would suit user applications (e.g., if Tc=10, then a 32 kbps CIR means 320 kbits in 10 seconds). Network providers prefer short intervals for Tc, as it eliminates the unpredictably of the data delivery; thus allowing for better network design. Most providers use a Tc value of 1 second.
CIR Operation
This visual shows how the class of service parameters interact. The graph shows the number of bits transmitted on the y-axis and time (in seconds) on the x-axis.
The line labeled access rate shows the actual transmission speed of the access interface, in bps. The CIR point represents Bc bits in Tc seconds. It is important to remember that CIR is an average. Consider a user with T-1/E-1 access (1.536/1.920 Mbps) to the network and a 256 kbps CIR for one permanent virtual circuit (PVC). When the customer premises equipment (CPE) transmits, the transmission rate will be 1.536/1.920 Mbps because that is the only data rate that the T-1/E-1 line accepts! While 1.536/1.920 Mbps is clearly greater than 256 kbps, the CIR only limits the average rate over time.
The user data arrival lines (i.e., the bold lines on the visual) show this concept of access rate versus CIR. At the beginning of the time interval Tc, the CPE transmits a frame. Since the CPE transmits at the actual access rate, the quantity of user data increases at the same slope as the access rate line. After transmitting the frame, the user sends no data and we see a flat user data arrival line. Later, the CPE sends a second frame. Again, the user data arrival line parallels the slope of the access rate line. At the end of this frame, this user is again idle. The total number of transmitted bits remains below the CIR throughout the Tc interval—the CIR is never exceeded.
At the end of the Tc measurement interval, the number of transmitted bits for this PVC is reset to zero, in preparation for the next interval.
CIR and Discard Eligibility
The graph shows the excess burst size (Be) parameter and use of the discard eligibility (DE) bit. In this example, the CPE transmits four frames. The first two frames are within the CIR because they totaled less than Bc bits in the Tc-second interval shown here.
Transmission of the third frame causes the total number of transmitted bits to exceed Bc (in fact, before the Tc interval completed) and violates the CIR agreement. The network, however, might not discard this frame. The network should be engineered to handle the excess burst. However, due to the fact that this frame is above the CIR, the network will mark it discard eligible by setting the DE-bit to 1 at the access node. The frame should then be sent through the network and not discarded unless severe network congestion is encountered at some other node in this or another network. Note some switch implementations do not set DE on the frame that exceeds the CIR; rather they wait until the next frame to set DE.
Being discard eligible and actually being discarded are two completely different things. Many service providers over-engineer their networks such that congestion is a rare occurrence. In the absence of congestion, discard eligibility means very little. In fact, some networks often offer delivery commitments in excess of 98 percent for DE = 1 frames. With this type of service only the most critical and loss-sensitive applications (e.g., voice/video or SNA) warrant traffic shaping and substantial CIR settings. Why should a customer bother to pay for and police CIR if it is supporting noncritical applications such as Internet access in an environment where the vast majority of traffic—discard eligible or not—will be delivered anyway?
The bottom line here is simple. The CIR parameter can be extremely significant, or a non-issue. This would be based on the service provider’s network design (i.e., its potential for congestion) and the applications used by the customer (whether they are loss/time-sensitive or not).
The fourth frame is discarded immediately by the first network node because the user has exceeded (Bc+Be) bits during the Tc time period (or CIR+EIR). Although the network can tolerate some excess, there is a limit!
Since the Be sets a limit above which frames will be immediately discarded regardless of congestion, it seems that this would be an important parameter for a network provider to discuss with its customers. Although there are no standard specifications for what the Be (or EIR) value should be, most carriers take a simple approach. They simply set Be equal to the rest of the available bandwidth, up to the access rate (i.e., CIR+EIR = access rate). Some switches can be configured to allow data in excess of Be; it’s just marked DE. However, use of this option is at the service provider’s discretion.
CPE Setting of Discard Eligibility
The frame relay standards do not preclude a customer from setting their own DE bits in an attempt to prioritize their traffic. A frame arriving at the ingress node with the DE bit set should be counted as excess (Be) data and not as committed (Bc) data even though the Bc parameter may not have been exceeded yet.
Many types of frame relay CPE can be configured to prioritize traffic using various mechanisms that may include setting the DE bit in frames considered “low priority.” Priority configurations within the FRAD can include such factors as the protocol type, application type, physical port, packet sizes, etc.
An example of such an application is shown on the visual. In this example the customer has a 64 kbps access line with a single PVC used to transport both compressed voice and LAN protocol traffic (multiple streams are being multiplexed onto the PVC). The PVC is configured for a 32 kbps CIR—Tc is set to one second in this example and Be is 32 kbits. At a minimum, the FRAD is configured with the following traffic shaping information: the PVC’s CIR and Be parameters, and the voice compression algorithm’s required bandwidth of 9600 bps.
The FRAD ensures that at all times there are at least 9600 bps of bandwidth for the voice application by imposing the traffic shaping rules shown on the graphic. In essence, the FRAD never sends more than 22.4 kbps of “non-Discard-Eligible” LAN traffic in a one second period. This “guarantees” that the voice application’s data passes through the network with the DE bit set to 0, minimizing the probability of the loss-sensitive voice packets being discarded due to network congestion.
Maximizing frame delivery probability using the mechanism described above does not necessarily guarantee the success of delay-sensitive applications such as voice or video. While the traffic may in fact be delivered, these applications are quite concerned with both maximum delay and delay variation parameters. Neither of these parameters can be set within frame relay’s QoS capabilities. Voice capable FRADs typically try to minimize delay through the use of high priority queues and data frame segmentation. These techniques minimize the delay introduced at the ends of the PVC (e.g., within the CPE), but do nothing to minimize the delay added by the frame relay network itself.
Note the standards do not make any provision for how a network should respond to DE bits set by the CPE. Before considering this approach it is recommended you speak to your frame relay provider to discover how their switches would respond to the CPE setting the DE bits.
Example Class of Service Parameter Values
It is difficult to describe such a large list of values only in relationship to each other. This visual gives some example values that reflect the “Be equal to the value of Bc” approach to excess burst size. Although in theory a different Be value could be established for each PVC, it is common practice for network engineering groups to establish a set relationship of Be—to either Bc or the remaining bandwidth—on a network-wide basis, and then apply it equally to all PVCs as a general network service parameter.
Most networks have standardized Tc to be one second. Since the CIR value and the Bc value are directly related, this one second setting means that they are equal in magnitude.
The visual shows a 64 kbps access rate, a 16 kbps CIR, and a 16 kbps EIR. Four frames are submitted to the network in the Tc interval. The first two frames are within the Bc quantity. Transmission of the third frame begins while still within that PVC’s CIR. Most frame relay switch vendors will not mark a frame discard eligible if its receipt begins while still within the CIR. However, this policy is not adhered to by all vendors. The fourth frame exceeds Bc, but is within Bc + Be, and therefore, is marked discard eligible before being forwarded through the network.
Oversubscription of CIR
Many network providers allow customers to oversubscribe the amount of CIR they are allocated on an access link. In this example, the customer has been allocated 200% of the bandwidth of the access rate.
Of course, the customer can send no more than 64 kbps across a 64 kbps access facility, so how does this work? This only works because of the bursty nature of data traffic. The definition of “bursty” traffic indicates that there will be relatively long intervals of time between the “bursts” of data. Data traffic that meets this definition is also a good candidate for oversubscription of CIR. The longer the interval between bursts, the better the fit of the data to oversubscription and the less likely that multiple PVCs will reach their CIR at the same time.
Another situation where oversubscription works well is when the PVC usage is mutually exclusive. Consider, for example, an environment where PVCs 16 and 18 are used during the day and PVCs 17, 19, and 20 are used at night.
Zero CIR
In 1994, a new twist was added to the CIR concept called “zero CIR.” A zero CIR provides a level of service consistent with its name. Specifically, users have a committed bandwidth of 0 bps. So, all frames transmitted to the network are at a rate in excess of the CIR and are, therefore, marked discard eligible.
Zero CIR was introduced for marketing purposes rather than technical ones, yet provides customers with a cost-effective use of frame relay’s bandwidth. Zero CIR depends on the statistical multiplexing of the user’s bursty applications to optimally share the bandwidth. It is also fair to the multiple applications running across a particular UNI if the traffic distribution on the multiple PVCs is very similar. Given the right circumstances, then, this scheme optimally uses network bandwidth and provides fair access for all users.
Zero CIR can be associated with usage-based billing. The network makes no promise of bandwidth, but only bills you for the actual traffic volume that you send (although there is usually some cap on the maximum charge). Most zero CIR users find that they save money with this approach.
Congestion Notification and CIR
Early implementations of frame relay services did not implement any of the congestion notification schemes. Today almost all of them implement forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN), but not consolidated link layer management (CLLM). While the standards specify how to inform devices about congestion, there are no specifications for action that must be taken on receipt of notification. Rather, there are recommendations on action to be taken.
Today most equipment manufacturers implement a variety of techniques for handling FECN/BECN. The simplest, and most common, is to scale back transmission to the CIR. In addition, many vendors allow for the setting of one or more user defined levels to which they can scale back; these are generally set to levels below the CIR—very important if the FRAD receives a FECN or BECN when transmitting below the CIR. Since most of the devices attached to the frame relay network are not the source of the congestion, scaling back is the simplest approach to handling network congestion. However, though it works well as a first level of defense, it does not reduce the amount of data being generated at the source. If congestion continues, the buffers in the access device will fill, thus requiring more drastic action to reduce the flow of information. For some protocols and devices, there are ways to reduce the rate at which traffic is generated. For example, a FRAD encapsulating Systems Network Architecture (SNA) traffic could reduce the data transmission window, thereby cutting back on the information flow. The precise scheme used depends upon the protocol in use.
PodSnacks
 | Committed Information Rate (CIR)
|
