USER DATA TRANSFER

USER DATA TRANSFER

The operation of frame relay for user data transfer is best explained by beginning

with the frame format, illustrated in Figure 10.7a. This is the format defined for the

minimum-function LAPF protocol (known as LAPF core protocol). The format is

similar to that of LAPD and LAPB with one obvious omission: There is no control

field.

0

0

9

This has the following implications:

There is only one frame type, used for carrying user data. There are no control

frames.

It is not possible to use inband signaling; a logical connection can only carry

user data.

It is not possible to perform flow control and error control, as there are no

sequence numbers.

The flag and frame check sequence (FCS) fields function as in LAPD and

LAPB. The information field carries higher-layer data. If the user selects to implement

additional data link control functions end-to-end, then a data link frame can

be carried in this field. Specifically, a common selection will be to use the full LAPF

protocol (known as LAPF control protocol) in order to perform functions above

the LAPF core functions. Note that the protocol implemented in this fashion is

strictly between the end subscribers and is transparent to ISDN.

The address field has a default length of 2 octets and may be extended to 3 or

4 octets. It carries a data link connection identifier (DLCI) of 10, 17, or 24 bits. The

DLCI serves the same function as the virtual circuit number in X.25: It allows multiple

logical frame relay connections to be multiplexed over a single channel. As in

X.25, the connection identifier has only local significance; each end of the logical

connection assigns its own DLCI from the pool of locally unused numbers: and the

network must map from one to the other. The alternative, using the same DLCI on

both ends, would require some sort of global management of DLCI values.

The length of the address field, and hence of the DLCI, is determined by the

address field extension (EA) bits. The C/R bit is application-specific and is not used

by the standard frame relay protocol. The remaining bits in the address field have

to do with congestion control, and are discussed in Section 10.6.

Figure 10.8 is another view of the protocols involved in frame relay, this time

from the point of view of the individual frame relay connections. There is a common

physical layer and frame relay sublayer. An optional layer-2 data link control

protocol may be included above the frame relay sublayer. This selection is application-

dependent and may differ for different frame relay connections (DLC-i). If

frame relay call control messages are carried in frame relay frames, they are carried

on DLCI 0, which provides a frame relay connection between the user and the

frame handler. DLCI 8191 is dedicated to management procedures.

Network Function

The frame relaying function performed by ISDN, or any network that supports

frame relaying, consists of the routing of frames with the format of Figure 10.7a,

based on their DLCI values.

Figure 10.9 suggests the operation of a frame handler in a situation in which a

number of users are directly connected to the same frame handler over different

physical channels. The operation could just as well involve relaying a frame through

two or more frame handlers. In this figure, the decision-making logic is shown conceptually

as a separate module: the frame relay control point. This module is

responsible for making routing decisions.

Typically, routing is controlled by entries in a connection table based on DLCI

that map incoming frames from one channel to another. The frame handler switches

a frame from an incoming channel to an outgoing channel, based on the appropriate

entry in the connection table, and translates the DLCI in the frame before transmission.

For example, incoming frames from TE B on logical connection 306 are

retransmitted to TE D on logical connection 342. The figure also shows the multiplexing

function: Multiple logical connections to TE D are multiplexed over the

same physical channel.

Note also that all of the TEs have a logical connection to the frame relay control

point with a value of DLCI = 0. These connections are reserved for in-channel

call control, to be used when 1.451lQ.931 on the D-channel is not used for frame

relay call control.

As part of the frame relay function, the FCS of each incoming frame is

checked. When an error is detected, the frame is simply discarded. It is the responsibility

of the end users to institute error recovery above the frame relay protocol.

10.6 CONGESTION CONTROL

In Section 9.3, we discussed the potentially disastrous effects of congestion on the

ability of network nodes to sustain throughput. To summarize that discussion, Figure

10.10 illustrates the effects of congestion in general terms. As the load on a network

increases, a region of mild congestion is reached, where the queuing delays at

the nodes results in increased end-to-end delay and reduced capability to provide

desired throughput. When a point of severe congestion is reached, the classic queu-

ing response results in dramatic growth in delays and a collapse in throughput.

It is clear that these catastrophic events must be avoided, which is the task of

congestion control. The object of all congestion control techniques is to limit queue

lengths at the frame handlers so as to avoid throughput collapse. This section provides

an overview of congestion control techniques developed as part of the frame

relay standardization effort.

Approaches to Frame Relay Congestion Control

ITU-T Recommendation 1.370 defines the objectives for frame relay congestion

control to be the following:

w Minimize frame discard

s Maintain, with high probability and minimum variance, an agreed quality of

service

s Minimize the possibility that one end user can monopolize network resources

at the expense of other end users

w Be simple to implement, and place little overhead on either end user or

network

s Create minimal additional network traffic

e Distribute network resources fairly among end users

e Limit spread of congestion to other networks and elements within the

network

e Operate effectively regardless of the traffic flow in either direction between

end users

w Have minimum interaction or impact on other systems in the frame relaying

network

w Minimize the variance in quality of service delivered to individual frame relay

connections during congestion (e.g., individual logical connections should not

experience sudden degradation when congestion approaches or has occurred)

The challenge of congestion control is particularly acute for a frame relay network

because of the limited tools available to the frame handlers. The frame relay

protocol has been streamlined in order to maximize throughput and efficiency; a

consequence of this is that a frame handler cannot control the flow of frames corning

from a subscriber or an adjacent frame handler using the typical sliding-window

flow control protocol, such as is found in LAPD.

Congestion control is the joint responsibility of the network and the end users.

The network (i.e., the collection of frame handlers) is in the best position to monitor

the degree of congestion, while the end users are in the best position to control

congestion by limiting the flow of traffic.

Table 10.3 lists the congestion control techniques defined in the various ITU-T

and ANSI documents. Discard strategy deals with the most fundamental response

to congestion: When congestion becomes severe enough, the network is forced to

discard frames; we would like to do this in a way that is fair to all users.

Congestion a oidance procedures are used at the onset of congestion to mini

mize the effect on the network. Thus, these procedures would be initiated at or

prior to point A in Figure 10.10 to prevent congestion from progressing to point B.

Near point A, there would be little evidence available to end users that congestion

is increasing. Thus, there must be some explicit signaling mechanism from the network

that will trigger the congestion avoidance.

Congestion recovery procedures are used to prevent network collapse in the

face of severe congestion. These procedures are typically initiated when the network

has begun to drop frames due to congestion. Such dropped frames will

be reported by some higher layer of software (e.g., LAPF control protocol), and

serve as an implicit signaling mechanism. Congestion recovery procedures operate

around point B and within the region of severe congestion, as shown in

Figure 10.10.

ITU-T and ANSI consider congestion avoidance with explicit signaling and

congestion recovery with implicit signaling to be complementary forms of congestion

control in the frame relaying bearer service.

Traffic Rate Management

As a last resort, a frame relaying network must discard frames to cope with congestion.

There is no getting around this fact. Because each frame handler in the network

has finite memory available for queuing frames (Figure 9.9), it is possible for

a queue to overflow, necessitating the discard of either the most recently arrived

frame or some other frame.

The simplest way to cope with congestion is for the frame relaying network to

simply discard frames arbitrarily, with no regard to the source of a particular frame.

In that case, because there is no reward for restraint, the best strategy for any individual

end system is to transmit frames as rapidly as possible; this, of course, exac

erbates the congestion problem'?

To provide for a fairer allocation of resources, the frame relaying bearer service

includes the concept of a committed information rate (CIR). This is a rate, in

bits per second, that the network agrees to support for a particular frame-mode connection.

Any data transmitted in excess of the CIR is vulnerable to discard in the

event of congestion. Despite the use of the term committed, there is no guarantee

that even the CIR will be met. In cases of extreme congestion, the network may be

forced to provide a service at less than the CIR for a given connection. However,

when it comes time to discard frames, the network will choose to discard frames on

connections that are exceeding their CIR before discarding frames that are within

their CIR.

In theory, each frame relaying node should manage its affairs so that the

aggregate of CIRs of all the connections of all the end systems attached to the node

do not exceed the capacity of the node. In addition, the aggregate of the CIRs

should not exceed the physical data rate across the user-network interface, known

as the access rate. The limitation imposed by the access rate can be expressed as

follows:

Considerations of node capacity may result in the selection of lower values for

some of the CIRs.

For permanent frame relay connections, the CIR for each connection must be

established at the time the connection is made between user and network. For

switched connections, the CIR parameter is negotiated; this is done in the setup

phase of the call control protocol.

The CIR provides a way of discriminating among frames in determining which

frames to discard in the face of congestion. Discrimination is indicated by means of

the discard eligibility (DE) bit in the LAPF frame (Figure 10.7). The frame handler

to which the user's station attaches performs a metering function (Figure 10.11). If

the user is sending data at less than the CIR, the incoming frame handler does not

alter the DE bit. If the rate exceeds the CIR, the incoming frame handler will set

the DE bit on the excess frames and then forward them; such frames may get

through or may be discarded if congestion is encountered. Finally, a maximum rate

is defined, such that any frames above the maximum are discarded at the entry

frame handler.

The CIR, by itself, does not provide much flexibility in dealing with traffic

rates. In practice, a frame handler measures traffic over each logical connection for

a time interval specific to that connection, and then makes a decision based on the

amount of data received during that interval. Two additional parameters, assigned

on permanent connections and negotiated on switched connections, are needed.

They are

Committed Burst Size (Bc). The maximum amount of data that the network

agrees to transfer, under normal conditions, over a measurement interval T.

These data may or may not be contiguous (i.e., it may appear in one frame or

in several frames).

e Excess Burst Size (Bc). The maximum amount of data in excess of Bc that the

network will attempt to transfer, under normal conditions, over a measurement

interval T. These data are uncommitted in the sense that the network

does not commit to delivery under normal conditions. Put another way, the

data that represent Be are delivered with lower probability than the data

within Bc,.

The quantities B, and CIR are related. Because Bc is the amount of committed

data that may be transmitted by the user over a time T, and CIR is the rate at

which committed data may be transmitted, we must have

 

over the measurement interval T. Note that when a frame is being transmitted, the

solid line is parallel to the Access Rate line; when a frame is transmitted on a channel,

that channel is dedicated to the transmission of that frame. When no frame is

being transmitted, the solid line is horizontal.

Part (a) of the figure shows an example in which three frames are transmitted

within the measurement interval, and the total number of bits in the three frames is

less than B,. Note that during the transmission of the first frame, the actual transmission

rate temporarily exceeds the CIR. This excess is of no consequence because

the frame handler is only concerned with the cumulative number of bits transmitted

over the entire interval. In part (b) of the figure, the last frame transmitted during

the interval causes the cumulative number of transmitted bits to exceed Bc. Accord

ingly, that DE bit of that frame is set by the frame handler. In part (c) of the figure,

the third frame exceeds B, and so is labeled for potential discard. The fourth frame

exceeds Bc + Be and is discarded.

This scheme is an example of a leaky bucket algorithm, and a mechanism for

implementing it is illustrated in Figure 10.13. The frame handler records the cumulative

amount of data sent over a connection in a counter C. The counter is decremented

at a rate of Bc every T time units. Of course, the counter is not allowed to

become negative, so the actual assignment is C ß MIN [C, Bc]. Whenever the

counter value exceeds Bc but is less than Bc + Be, incoming data are in excess of the

committed burst size and are forwarded with the DE bit set. If the counter reaches

Bc + Be, all incoming frames are discarded until the counter has been decremented.

Congestion Avoidance with Explicit Signaling

It is desirable to use as much of the available capacity in a frame relay network as

possible but still react to congestion in a controlled and fair manner. This is the purpose

of explicit congestion avoidance techniques. In general terms, for explicit congestion

avoidance, the network alerts end systems to growing congestion within the

network and the end systems take steps to reduce the offered load to the network.

As the standards for explicit congestion avoidance were being developed, two

general strategies were considered [BERG91]. One group believed that congestion

always occurred slowly and almost always in the network egress nodes. Another

group had seen cases in which congestion grew very quickly in the internal nodes

and required quick, decisive action to prevent network congestion. We will see that

these two approaches are reflected in the forward and backward explicit congestion

avoidance techniques, respectively.

For explicit signaling, two bits in the address field of each frame are provided.

Either bit may be set by any frame handler that detects congestion. If a frame handler

receives a frame in which one or both of these bits are set, it must not clear the

bits before forwarding the frame. Thus, the bits constitute signals from the network

to the end user. The two bits are

Backward explicit congestion notification (BECN). Notifies the user that congestion

avoidance procedures should be initiated where applicable for traffic

in the opposite direction of the received frame. The notification indicates that

the frames transmitted by the user on this logical connection may encounter

congested resources.

Forward explicit congestion notification (FECN). Notifies the user that congestion

avoidance procedures should be initiated where applicable for traffic

in the same direction as the received frame. The notification indicates that this

frame, on this logical connection, has encountered congested resources.

Let us consider how these bits are used by the network and the user. First, for

the network response, it is necessary for each frame handler to monitor its queuing

behavior. If queue lengths begin to grow to a dangerous level, then either FECN or

BECN bits, or a combination, should be set to try to reduce the flow of frames

through that frame handler. The choice of FECN or BECN may be determined by

whether the end users on a given logical connection are prepared to respond to one

or the other of these bits; this may be determined at configuration time. In any case,

the frame handler has some choice as to which logical connections should be alerted

to congestion. If congestion is becoming quite serious, all logical connections

through a frame handler might be notified. In the early stages of congestion, the

frame handler might just notify users for those connections that are generating the

most traffic.

In an lesson to ANSI T1.618, a procedure for monitoring queue lengths is

suggested. The frame handler monitors the size of each of its queues. A cycle begins

when the outgoing circuit goes from idle (queue empty) to busy (non-zero queue

size, including the current frame). The average queue size over the previous cycle

and the current cycle is calculated. If the average size exceeds a threshold value,

then the circuit is in a state of incipient congestion, and the congestion avoidance

bits should be set on some or all logical connections that use that circuit. By averaging

over two cycles instead of just monitoring current queue length, the system

avoids reacting to temporary surges that would not necessarily produce congestion.

The average queue length may be computed by determining the area (product

of queue size and time interval) over the two cycles and dividing by the time of

the two cycles. This algorithm is illustrated in Figure 10.14.

The user response is determined by the receipt of BECN or FECN signals. The

simplest procedure is the response to a BECN signal: The user simply reduces the

rate at which frames are transmitted until the signal ceases. The response to an

FECN is more complex, as it requires the user to notify its peer user of this connection

to restrict its flow of frames. The core functions used in the frame relay pro

tocol do not support this notification; therefore, it must be done at a higher layer,

such as the transport layer. The flow control could also be accomplished by the

LAPF control protocol or some other link control protocol implemented above the

frame relay sublayer (Figure 10.8). The LAPF control protocol is particularly useful

because it includes an enhancement to LAPD that permits the user to adjust

window size.

Congestion Recovery with Implicit Signaling

Implicit signaling occurs when the network discards a frame, and this fact is

detected by the end user at a higher, end-to-end layer, such as the LAPF control

protocol. When this occurs, the end user software may deduce that congestion

exists.

For example, in a data link control protocol such as the LAPF control protocol,

which uses a sliding-window flow and error control technique, the protocol

detects the loss of an I frame in one of two ways:

1. When a frame is dropped by the network, the following frame will generate

an REJ frame from the receiving end point.

2. When a frame is dropped by-the network, no acknowledgment is returned

from the other end system. Eventually, the source end system will time out

and transmit a command with the P bit set to 1. The subsequent response with

the F bit set to 1 should indicate that the receive sequence number N(R) from

the other side is less than the current send sequence number.

Once congestion is detected, the protocol uses flow control to recover from

the congestion. LAPF suggests that a user that is capable of varying the flow con

trol window size use this mechanism in response to implicit signaling. Let us assume

that the layer-2 window size, W, can vary between the parameters Wmin and W,,,,

and is initially set to W,,,. In general, we would like to reduce W, as congestion

increases, to gradually throttle the transmission of frames. Three classes of adaptive

window schemes based on response to one of the two conditions listed above have

been suggested [CHEN89, DOSH881: