Frame Relay - for Faster and More Efficient Data Communications ...

More documents

Recommendations

Info

8Fig. 11The frame format used for Frame RelayFig. 12The address field of the frame used for FrameRelay consists of a DLCI and control /check informationfor flow handlingC/REAFECN6ECNDECommand/Response indication bitExtended Address bitsForward Explicit Congestion Notification bitBackward Explicit Congestion Notication bitDiscard Eligibility bit2 Mbit/s, but considerably higher speedscan be expected.Frame StructureThe frame format used for Frame Relay isbased on LAPD (Link Access Protocol D),which has been specified by CCITT(Q.922) and ANSI (T1.618). The frame,Fig. 11, is used to carry both user data andidentification code (DLCI). The header ofthe LAPD frame consists of two byte andcontains - in addition to the 10-bit DLCI -information bits for flow control (BECN,FECN and a DE bit; see below).The length of the information field in theLAPD frame is adjustable to a maximumvalue defined for the service concerned.The length is normally set to a value atwhich the information from the application- a TCP/IP packet, an SDLC frame, anX.25 packet, etc - can be carried withouthaving to be split.The frame ends in a Frame Checking Sequence,FCS, which is used to check thatthe frame has been transferred correctly.As opposed to X.25, where an erroneousFCS triggers a retransmission procedureover the link, the network cannot guaranteethat all frames will reach their destination.Frames indicated as erroneous by theFCS are discarded, but this does not necessarilymean that the user loses any data.Checking to ensure that the DTE-to-DTEtransmission has been error-free is usuallya mandatory function in the higher-levelprotocol used for information transfer inthe application concerned. If an error occurs,data must be retransmitted throughthe entire network, and this obviouslytakes longer time than retransmission onlyover the link on which the error occurred.An approximate limit where Frame Relayis effective is a Bit Error Ratio (BER) of nomore than 1/1,000,000 on individual links.This means that modern, digital transportnetworks are well suited for the simplifiedprotocol, but if the chain contains an analoglink, a short delay time for each linkmust be weighed against the expected frequencyof end-to-end retransmission.Flow control and handling of overloadsituationsThe handling of an overload situation in aFrame Relay network demands less of theswitching equipment than handling the samesituation in an X.25 network. In the lattercase, the flow is controlled by the networknode sending confirmation messagesin the backward direction to the DTE,to the effect that sending may go on. If nomessage is forthcoming, the DTE will stopsending new packets until it has receiveda confirmation. This rule ensures a controlledand stable system, at the cost of delayedtransfer.ERICSSON REVIEW No. 1-2, 1992
9Fig. 13Applications which use sophisticated graphicsand therefore generate very large files are becomingmore and more frequent. Transferthrough the network requires a transmissionspeed of several Mbit s to obtain a reasonable responsetime. Local networks are well adapted tothis requirement, but in wide area network transferthere may be inconveniences, since thesenetworks did not initially have the infrastructurerequired for high transmission speeds.In pace with the digitalisation of the wide areanetworks, new communication protocols are nowevolving, the development of them being to alarge extent driven by the demand for efficientLAN-to-LAN communication. Frame Relay is oneexample of this trendFrame Relay is based on the opposite principle:the network node sends signals tothe DTE only in overload situations. Thismeans simplified handling, and no delayswill occur as long as the traffic is undisturbed.A Frame Relay network reacts tooverload in two steps:1 When the node registers a tendency towardsoverload, the network requeststhe DTE to reduce its data flow by sendinga Forward/Backward Explicit CongestionNotification (FECN/BECN) consistingof the check bits of the frameheader, Fig. 12. The network takes noaction but leaves it to the DTE to decideon the best way of controlling its dataflow.2 If overload occurs, the network will discardframes.The standard does not say how the networkwill define the concept "tendency towardsoverload". To exemplify, the nodecan count the number of frames queuedfor access to outgoing lines, or check theCPU load, and then send an FECN/BECNsignal when a preset limit value is exceeded.As has been mentioned already, a discardedframe in the network will not result inloss of information. The higher-level userapplication protocol checks that the terminatingDTE sends a confirmation of datahaving arrived. If no such confirmation isreceived, retransmission through the entirenetwork will be initiated, resulting in undesireddelays, i.e. longer response time.Transferring the flow control to the DTEclearly involves a risk, since most oftoday's frame-relay-compatible DTEs cannothandle FECN and BECN signals. Somesuppliers of equipment capable of handlingFECN/BECN signals recommend usersto switch off the function in order toavoid falling behind when competing fortransport capacity with equipment withoutthat function.For the simplified flow handling to functionproperly, each connection from a DTE isallocated a Committed Information Rate,CIR. This rate is affiliated to the virtual connectionthrough the network, and the ratevalue determines how much data the DTEcan send on this connection during a givenperiod of time.The standard does not give a strict definitionof how to use the CIR value. It could,for example, be chosen so that each PVCwould be guaranteed access to a given bitflow, which would basically be the sameas using a leased line. A 2 Mbit/s connectionwould then be able to carry 32 PVCsof 64 kbit/s each. However, a more rationaluse will be ensured by starting from thestochastic traffic characteristics and interpretingCIR as a stochastic value of the averageamount of data that a PVC is expectedto carry during a given period of integration.Since the traffic is in the form ofbursts, there is little probability of all sourcessending at the same time. In otherwords, we can allow a PVC to momentarilyutilise a relatively large portion of theavailable transmission capacity, providedthe stipulated average value is kept. At anintegration time of, say, 0.5 s, a CIR valueof 256 kbit/s for a PVC will mean that theDTE can use this PVC for sending one ormore bursts of altogether 128 kbit duringeach 500 ms interval.Assigning CIR values will facilitate calculationof the traffic flow through the network.When the CIR value is exceeded,the Discard Eligibility bit in the frame head-ERICSSON REVIEW No. 1-2. 1992
Page 1: ERICSSONREVIEW1-21992Frame Relay -
Page 4 and 5: ERICSSON REVIEWBO HEDFORSPublisher
Page 6 and 7: 4Fig. 2Distributed computer environ
Page 8 and 9: Fig. 7A company's data network shou
Page 12 and 13: 10er (DE, Fig. 12) should be set to
Page 14 and 15: Computerised System for QualityInsp
Page 16 and 17: Box 1Code39, the first alphanumeric
Page 18 and 19: 16Fig. 6Cable attenuation test at E
Page 20 and 21: 18Fig. 9Installing the Dehlfi syste
Page 22 and 23: Human Factors - A Key to ImprovedQu
Page 24 and 25: 221 Use the user's model2 Introduce
Page 26 and 27: 24Fig. 5Advanced Human Factors desi
Page 28 and 29: Fig. 7User interface for PBX attend
Page 30 and 31: Cell-voltage EqualisersSeries BMP 1
Page 32 and 33: 30Box1CELL-VOLTAGE EQUALISER BMP 16
Page 34 and 35: 32age, the faulty cell or the entir
Page 36 and 37: In Search of Managed ObjectsWalter
Page 38 and 39: Fig. 4The telecommunication network
Page 40 and 41: Fig. 6Functional Model illustrating
Page 42 and 43: 40Fig. 9Combination of layering and
Page 44 and 45: 42Table 2Relationship between Funct
Page 46 and 47: 44No1PPI2PPI3SLTTransport Function(
Page 48 and 49: 46Table 4SDH functions, Resources a
Page 50 and 51: The Managed Objects and their prope
Page 52 and 53: 50Fig. 21Information Model of PDH d
Page 54 and 55: Fig. 25Information Model of SDH mul
Page 56 and 57: 54Table 5Cross-connect functions, R
Page 58: Fig. 32, leftCross-connect Fragment

Frame Relay - for Faster and More Efficient Data Communications ...

Create successful ePaper yourself

Delete template?

Save as template?