Biblio5

However, the procedures for packet access through the B-channel or the D-channel are different.

In both cases of B- and D-channel accesses, in the service of Case B, the address of the called DTE is contained in the X.25 call request packet. The establishment of the physical connection from the TA/ TE1 to the packet handling function is done on the basis of the requested bearer service (ISDN virtual circuit service), and therefore the user does not provide any addressing information in the layer procedures (D-channel, Q.931).

12.5 SPEEDING UP THE NETWORK: FRAME RELAY

12.5.1 Rationale and Background

It would seem from the terminology and the popular press that somehow we were making bits travel faster down the pipe; that by some means we had broken the velocity barrier by dramatically increasing the velocity of propagation. Of course, this is patently not true.

If bandwidth permits, bit rate can be increased.12 That certainly will speed things up. One way to get around the bandwidth crunch is to work around the analog voice channel; use some other means. ISDN was a step in that direction; use coaxial cable and fiber optics as the cable television people do.

Probably the greatest impetus to speed up the network came from LAN users who wished to extend LAN connectivity to distant destinations. Ostensibly this traffic, as described in Chapter 11, has local transmission rates from 4 Mbps to 100 Mbps, with gigabit rates in the near future. X.25 WAN connectivity was one possible answer. Its packet circuits are slow and tedious, but very robust, even on circuits with poor error performance. There must be a better way with our digital network and its sterling error performance.

What slows down X.25 service? X.25 commonly operates at 64 kbps, and is even feasible at T1/ E1 transmission rates. What slows things down is X.25’s intensive processing at every node and continual message exchange as to the progress of packets, from node to originator and from node to destination. See Table 12.3 for a comparison between X.25 and frame relay.

On many X.25 connectivities, multiple nodes are involved, slowing service still further. One clue lies in the fact that X.25 was designed for circuits with poor transmission performance. This is manifested in degraded error rates, on the order of 1 × 10−4. Meanwhile, the underlying digital networks in North America display end-to-end error performance better than 1 × 10−7. Sprint calls for digital-link performance of 1 × 10−12. Such excellent error performance begs the questions of removing the responsibility of error recovery from the service provider. If errors statistically occur in about 1 in 10 million bits, there is a strong argument for removing error recovery, at least in the data-link layer. In fact, with frame relay the following salient points emerge:

•There is no process for error recovery by the frame relay service provider.

•The service provider does not guarantee delivery nor are there any sort of acknowledgments provided.

12“If bandwidth permits:” We cannot increase bandwidth as the popular press insinuates. We can make better use of bandwidth. With data transmission, particularly as the bit rate increases, other bandwidth constraints, besides amplitude response, may become the limiting factor on bit rate. Typically this may be group delay (envelope delay distortion), bandwidth coherence.

372 ENTERPRISE NETWORKS II: WIDE AREA NETWORKS

Table 12.3 Functional Comparison of X.25 and Frame Relay

•It only uses the first two OSI layers (physical and data-link layer), thus removing layer 3 and its intensive processing requirements.

•Frame overhead is kept to a minimum, to minimize processing time and to increase useful throughput.

•There is no control field, and no sequence numbering.

•Frames are discarded without notifying originator for such reasons as congestion and having encountered an error.

•It operates on a statmultiplex concept.

In sum, the service that the network provides can be speeded up by increasing data rate, eliminating error-recovery procedures, and reducing processing time. One source states that a frame relay frame takes some 20 ms to reach the distant end (statistically), where an X.25 packet of similar size takes in excess of 200 ms on terrestrial circuits inside CONUS (CONUS stands for contiguous United States).

Another advantage of frame relay over a conventional static TDM connection is that it uses virtual connections. Data traffic is often bursty and normally would require much larger bandwidths to support the short data messages and much of the time that bandwidth would remain idle. Virtual connections of frame relay only use the required bandwidth for the period of the burst or usage. This is one reason why frame relay is used so widely to interconnect LANs over a wide area network (WAN). Figure 12.28 shows a tpyical frame relay network.

374 ENTERPRISE NETWORKS II: WIDE AREA NETWORKS

To properly describe frame relay from our perspective, we will briefly give an overview of the ANSI T1.618-1991 (Ref. 23) and T1.606-1990 (Ref. 24). This will be followed by some fairly well identified variants.

12.5.3 Introduction to Frame Relay Operation

Frame relay may be considered a cost-effective outgrowth of ISDN, meeting high data rate (e.g., 2 Mbps) and low delay data communications requirements. Frame relay encapsulates data files. These may be considered “packets,” although they are called frames. Thus frame relay is compared to CCITT Rec. X.25 packet service. Frame relay was designed for current transmission capabilities of the network with its relatively wider bandwidths14 and excellent error performance (e.g., BER better than 1 × 10−7).

The incisive reader will note the use of the term bandwidth. It is used synonymously with bit rate. If we were to admit at first approximation 1 bit per hertz of bandwidth, such use is acceptable. We are mapping frame relay bits into bearer channel bits probably on a one-for-one basis. The bearer channel may be a DS0/ E0 64-kbps channel, a 56-kbps channel of a DS1 configuration, or multiple DS0/ E0 channels in increments of 64 kbps up to 1.544/ 2.048 Mbps. We may also map the frame relay bits into a SONET or SDH configuration (Chapter 17). The final bearer channel may require more or less bandwidth than that indicated by the bit rate. This is particularly true for such bearer channels riding on radio systems and, to a lesser extent, on a fiber-optic medium or other transmission media. The reader should be aware of certain carelessness of language used in industry publications.

Frame relay works well in the data rate range from 56 kbps up to 1.544/ 2.048 Mbps. It is being considered for the 45-Mbps DS3 rate for still additional speed.

ITU-T’s use of the ISDN D-channel for frame relay favors X.25-like switched virtual circuits (SVCs). However, ANSI recognized that the principal application of frame relay was interconnection of LANs, and not to replace X.25. Because of the high data rate of LANs (megabit range), dedicated connections are favored. ANSI thus focused on permanent virtual connections (PVCs). With PVCs, routes are provisioned at the time of frame relay contract. This notably simplified the signaling protocol. Also, ANSI frame relay does not support voice or video.

As mentioned, the ANSI frame relay derives from ISDN LAPD core functions. The core functions of the LAPD protocol that are used in frame relay (as defined here) are as follows:

•Frame delimiting, alignment, and transparency provided by the use of HDLC flags and zero bit insertion/ extraction;15

/demultiplexing using the address field;16

•Inspection of the frame to ensure that it consists of an integer number of octets prior to zero bit insertion or following zero bit extraction;

•Inspection of the frame to ensure that it is not too long or too short;

•Detection of (but not recovery from) transmission errors; and

•Congestion control functions.

14We would rather use the term greater bit rate capacity.

15Zero bit insertion is a technique used to assure that the unique beginning flag of a frame is not imitated inside the frame that allows full transparency.

16Where the DLCI indicates a particular channel or channel group in the multiplex aggregate for PVC operation.

Figure 12.29 Frame relay ANSI frame format with a two-octet address. DLCI—data link connection identifier, C/ R—command response indicator, EA–address field extension bit, FECN/ BECN—see text, DE—discard eligibility.

In other words, ANSI has selected certain features from the LAPD structure/ protocol, rejected others, and added some new features. For instance, the control field was removed, but certain control functions have been incorporated as single bits in the address field. These are the C/ R bit (command/ response), DE (discard eligibility), FECN bit (forward explicit congestion notification), and BECN bit (backward explicit congestion notification).

12.5.4 Frame Structure

User traffic passed to a FRAD (frame relay access device) is segmented into frames with a maximum length information field or with a default length of 262 octets. The minimum information field length is one octet.

Figure 12.29 illustrates the frame relay frame structure. As mentioned before in Section 12.4.8 (LAPD), it uses HDLC flags (01111110) as opening and closing flags. A closing flag may also serve as the opening flag of the next frame.

Address field. This consists of two octets, but may be extended to three or four octets. However, there is no control field as there is in HDLC, LAPB, and ISDN LAPD.

In its most reduced version, there are just 10 bits allocated to the address field in two octets (the remainder of the bits serve as control functions) supporting up to 1024 logical connections.

It should be noted that the number of addressable logical connections is multiplied because they can be reused at each nodal (switch) interface. That is, an address in the form of a data-link connection identifier (DLCI) has meaning only on one trunk between adjacent nodes. The switch (node) that receives a frame is free to change the DLCI before sending the frame onwards over the next link. Thus, the limit of 1024 DLCIs applies to the link, not the network.

Information field. This follows the address field and precedes the frame check sequence (FCS). The maximum size of the information field is an implementation parameter, and the default maximum is 262 octets. ANSI chose this default maximum to be compatible with LAPD on the ISDN D-channel, which has a two-octet control field and a 260-octet maximum information field. All other maximum values are negotiated between users and networks and between networks. The minimum information field size is one octet. The field must contain an integer number of octets; partial octets are not allowed. A maximum of 1600 octets is encouraged for applications such as LAN interconnects to minimize the need for segmentation and reassembly by user equipment.

376 ENTERPRISE NETWORKS II: WIDE AREA NETWORKS

Transparency. As with HDLC, X.25 (LAPB), and LAPD, the transmitting data-link layer must examine the frame content between opening and closing flags and inserts a 0 bit after all sequences of five contiguous 1s (including the last five bits of the FCS) to ensure a flag or an abort sequence is not simulated within the frame. At the other side of the link, a receiving data-link layer must examine the frame contents between the opening and closing flags and must discard any 0 bit that directly follows five contiguous 1s.

Frame check sequence (FCS). This is based on the generator polynomial X16 + X12 + X5 + 1. The CRC processing includes the content of the frame existing between, but not including, the final bit of the opening flag and the first bit of the FCS, excluding the bits inserted for transparency. The FCS, of course, is a 16-bit sequence. If there are no transmission errors (detected), the FCS at the receiver will have the sequence 00011101 00001111.

Invalid frames. An invalid frame is a frame that:

•Is not properly bounded by two flags (e.g., a frame abort);

•Has fewer than three octets between the address field and the closing flag;

•Does not consist of an integral number of octets prior to zero bit insertion or following zero bit extraction;

•Contains a frame check sequence error;

•Contains a single octet address field; and

•Contains a data-link connection identifier (DLCI) that is not supported by the receiver.

Invalid frames are discarded without notification to the sender, with no further action.

12.5.4.1 Address Field Variables

12.5.4.1.1 Address Field Extension Bit (EA). The address field range is extended by reserving the first transmitted bit of the address field octets to indicate the final octet of the address field. If there is a 0 in this bit position, it indicates that another octet of the address field follows this one. If there is a 1 in the first bit position, it indicates that this octet is the final octet of the address field. As an example, for a two-octet address field, bit one of the first octet is set to 0 and bit one of the second octet is set to 1.

It should be understood that a two-octet address field is specified by ANSI. It is a user’s option whether a threeor four-octet field is desired.

12.5.4.1.2 Command/ Response Bit (C/ R). The C/ R bit is not used by the ANSI protocol, and the bit is conveyed transparently.

12.5.4.1.3 Forward Explicit Congestion Notification (FECN) Bit. This bit may be set by a congested network to notify the user that congestion avoidance procedures should be initiated, where applicable, for traffic in the direction of the frame carrying the FECN indication. This bit is set to 1 to indicate to the receiving end-system that the frames it receives have encountered congested resources. The bit may be used to adjust the rate of destination-controlled transmitters. While setting this bit by the network or user is optional, no network shall ever clear this bit (i.e., set to 0). Networks that do not provide FECN shall pass this bit unchanged.

12.5.4.1.4 Backward Explicit Congestion Notification (BECN). This bit may be set by a congested network to notify the user that congestion avoidance procedures should be initiated, where applicable, for traffic in the opposite direction of the frame carrying the BECN indicator. This bit is set to 1 to indicate to the receiving end-system that the frames it transmits may encounter congested resources. The bit may be used to adjust the rate of source-controlled transmitters. While setting this bit by the network or user is optional according to the ANSI specification, no network shall ever clear (i.e., set to 0) this bit. Networks that do not provide BECN shall pass this bit unchanged.

12.5.4.1.5 Discard Eligibility Indicator (DE) Bit. This bit, if used, is set to 1 to indicate a request that a frame should be discarded in preference to other frames in a congestion situation. Setting this bit by the network or user is optional. No network shall ever clear (i.e., set to 0) this bit. Networks that do not provide DE capability shall pass this bit unchanged. Networks are not constrained to only discard frames with DE equal to 1 in the presence of congestion.

12.5.4.1.6 Data-Link Connection Identifier (DLCI). This is used to identify the logical connection, multiplexed within the physical channel, with which a frame is associated. All frames carried within a particular physical channel and having the same DLCI value are associated with the same logical connection. The DLCI is an unstructured field. For two-octet addresses, bit 5 of the second octet is the least significant bit. For threeand four-octet addresses, bit 3 of the last octet is the least significant bit. In all cases, bit 8 of the first octet is the most significant bit. The structure of the DLCI field may be established by the network at the user–network interface subject to bilateral agreements.

12.5.5 Traffic and Billing on a Frame Relay Network.

Figure 12.30a shows a typical traffic profile on a conventional PSTN, whereas Figure 12.30b illustrates a typical profile of bursty traffic over a frame relay network. Such a traffic profile is also typical of a LAN. Of course the primary employment of frame relay is to interconnect LANs at a distance.

With conventional leased data circuits we have to pay for the bit rate capacity whether it is used or not. On the other hand, with frame relay, we only pay for the “time” used. Billing can be handled in one of three ways:

Figure 12.30a A typical traffic profile of a public switched telephone network. (Courtesy of HewlettPackard Co., Ref. 25.)

378 ENTERPRISE NETWORKS II: WIDE AREA NETWORKS

Figure 12.30b Typical bursty traffic of a frame relay circuit. Note the traffic levels indicated. (Courtesy of Hewlett-Packard Co., Ref. 25.)

1. CIR (committed information rate) is a data rate subscribed to by a user. This rate may be exceeded for short bursts during peak period(s) as shown in Figure 13.30b.

2. We can just pay a flat rate.

3. We can pay per packet (i.e., frame).

Now turn to Figure 12.30b. Note that on the right-hand side of the figure there is the guaranteed transmission bit rate equivalent to the CIR. Depending on the traffic load and congestion, during short periods the user may exceed the CIR. However, there is a point where the network cannot sustain further increases in traffic without severe congestion resulting. Traffic above such levels is arbitrarily discarded by the network without informing the originator.

12.5.6 Congestion Control: A Discussion

Congestion in the user plane occurs when traffic arriving at a resource exceeds the network’s capacity. It can also occur for other reasons such as equipment failure. Network congestion affects the throughput, delay, and frame loss experienced by the end-user.

End-users should reduce their offered load in the face of network congestion. Reduction of offered load by an end-user may well result in an increase in the effective throughput available to the end-user during congestion.

Congestion avoidance procedures, including optional explicit congestion notification, are used at the onset of congestion to minimize its negative effects on the network and its users. Explicit notification is a procedure used for congestion avoidance and is part of the data-transfer phase. Users should react to explicit congestion notification (i.e., optional but highly desirable). Users who are not able to act on explicit congestion notification shall have the capability to receive and ignore explicit notification generated by the networks.

Congestion recovery and the associated implicit congestion indication due to frame discard are used to prevent network collapse in the face of severe congestion. Implicit congestion detection involves certain events available to the protocols operating above the core function to detect frame loss (e.g., receipt of a REJECT frame, timer recovery). Upon detection of congestion, the user reduces the offered load to the network. Use of such reduction by users is optional.

12.5.6.1 Network Response to Congestion. Explicit congestion signals are sent in both the forward direction (toward the frame destination) and in the backwards direction (toward the frame source or originator). Forward explicit congestion notification (FECN) is provided by using the FECN bit (see Figure 12.29) in the address field. Backward explicit congestion notification (BECN) is provided by one of two methods. When timely reverse traffic is available, the BECN bit in the appropriate address field may be used. Otherwise, a consolidated link layer management message may be generated by the network. The consolidated link layer management (CLLM) message travels on the network as though it were a conventional frame relay frame. The generation and transport of CLLM by the network are optional. All networks transport the FECN and BECN bits without resetting.

12.5.6.2 User Response to Congestion. Reaction by the end-user to the receipt of explicit congestion notification is rate-based. Annex A to ANSI T1.618-1991 (Ref. 23) describes user reaction to FECN and BECN.

12.5.6.2.1 End-User Equipment Employing Destination-Controlled Transmitters.

End-user reaction to implicit congestion detection or explicit congestion notification (FECN indications), when supported, is based on the values of FECN indications that are received over a period of time. The method is consistent with commonly used destination-controlled protocol suites, such as OSI class 4 transport protocol operated over the OSI connectionless service.

12.5.6.2.2 End-User Equipment Employing Source-Controlled Transmitters. Enduser reaction to implicit congestion notification (BECN indication), when supported, is immediate when a BECN indication or a CLLM is received. This method is consistent with implementation as a function of data-link layer elements of procedure commonly used in source-controlled protocols such as CCITT Rec. Q.922 elements of procedure.

12.5.6.3 Consolidated Link Layer Management (CLLM) Message. The CLLM utilizes a special type of frame which has been appropriated from the HDLC protocol. This is the XID frame, commonly called an exchange identification frame. In HDLC it was used just as the name implied, for exchange identification. In frame relay, however, it may be used for network management as an alternative to congestion control. CLLM messages originate at network nodes, near the frame relay interface, usually housed in a router or otherwise incorporated with operational equipment.

As mentioned, BECN/ FECN bits in frames must pass congested nodes in the forward or backward direction. Suppose that, for a given user, no frames pass in either direction, and that the user therefore has no knowledge of network congestion because at that moment the user is not transmitting or receiving frames. Frame relay standards do not permit a network to generate frames with the DLCI of the congested circuit. CLLM covers this contingency. It has DLCI c 1023 reserved.

The use of CLLM is optional. If it is used, it may or may not operate in conjunction with BECN/ FECN. The CLLM frame format has one octet for the cause of congestion such as excessive traffic, equipment or facility failure, preemption, or maintenance action.

This same octet indicates whether the cause is expected to be short or long term. Short term is on the order of seconds or minutes, and anything greater is long term. There is also a bit sequence in this octet indicating an unknown cause of congestion and whether short or long term.

380 ENTERPRISE NETWORKS II: WIDE AREA NETWORKS

CLLM octets 19 and above give the DLCI values that identify logical links that have encountered congestion. This field must accommodate DLCI length such as two-octet, three-octet, and four-octet DLCI fields.

12.5.6.4 Action at a Congested Node. When a node is congested, it has several alternatives it may use to mitigate or eliminate the problem. It may set the FECN and BECN bits to a binary 1 in the address field and/ or use the CLLM message. Of course, the purpose of explicit congestion notification is:

•To inform the “edge” node at the network ingress of congestion so that edge node can take the appropriate action to reduce the congestion; or

•To notify the source that the negotiated throughput has been exceeded; or

•To do both.

One of the strengths of the CLLM is that it contains a list of DLCIs that correspond to the congested frame relay bearer connections. These DLCIs indicate not only the sources currently active causing the congestion, but also those sources that are not active. The reason for the latter is to prevent those sources that are not active from becoming active and thus causing still further congestion. It may be necessary to send more than one CLLM message if all the affected DLCIs cannot fit into a single frame.

12.5.7 Quality of Service Parameters

The quality that frame-relaying service provides is characterized by the values of the following parameters. ANSI adds in Ref. 24 that the specific list of negotiable parameters is for further study.

1. Throughput;

2. Transit delay;

3. Information integrity;

4. Residual error rate;

5. Delivered error(ed) frames;

6. Delivered duplicated frames;

7. Delivered out-of-sequence frames;

8. Lost frames;

9. Misdelivered frames;

10. Switched virtual call establishment delay;

11. Switched virtual call clearing delay;

12. Switched virtual call establishment failure;

13. Premature disconnect; and

14. Switched virtual call clearing failure.

12.5.7.1 Network Responsibilities. Frame relay frames are routed through the network on the basis of an attached label (i.e., the DLCI value of the frame). This label is a logical identifier with local significance. In the virtual call case, the value of the logical identifier and other associated parameters such as layer 1 channel delay, and so on, may be requested and negotiated during call setup. Depending on the value of the