Frame Relay - for Faster and More Efficient Data Communications ...
Frame Relay - for Faster and More Efficient Data Communications ... Frame Relay - for Faster and More Efficient Data Communications ...
Fig. 7A company's data network should be designedso as to permit both existing and future applicationsto use the same physical networkBox 1Standardisation of Frame RelayFrame Relay as a communications standard wasfirst proposed by CCITT in the late 80's and thenpresented in Recommendation 1.122. At that time,the US standardisation body ANSI had also beganto take an interest in this field, but the resultof both bodies' work was rather long in coming.Northern Telecom, DEC, CISCO, and Stratacomtherefore took the matter in their own hands, submittingat the end of 1990 a proposal for a standardbased on the existing - but still incomplete -proposals drawn up by CCITT and ANSI. This proposalalso contained a "Local Management Interface",LMI, which describes the exchange of informationon link status between the DTEs andthe network. To complete the work and force thepace of standardisation, Frame Relay Forum wasestablished in January, 1991.More than 70 companies including Ericsson arenow members of Frame Relay Forum, which doesnot do any standardisation work of its own but submitsproposals to existing standardisation bodiessuch as CCITT, ANSI and ETSI. The formation ofFrame Relay Forum speeded up the standardisationwork, and the CCITT and ANSI standardshave now reached an appreciable degree of development,including the specification of LMI functionality.CCITT's recommendations include I.223 (whichdescribes the service), Q.922 (describing theframe) and 0.933 (signalling). ANSI's versions ofthese standards, which are basically equivalent tothose specified by CCITT, are called T1.606 (theservice), T1.618 (frame) and T1.617 (signalling).(PVC) and Virtual Connections (VC). ThePermanent Virtual Connection is a networkpath which is predefined by the networkoperator. The procedure for setting up aVirtual Connection includes indication ofthe address by means of a Network TerminalNumber, which is unique to each setof equipment connected. No network operatoris involved in this set-up procedure,which results in the establishment of a networkpath that remains connected until thesender or receiver orders its release.The X.25 protocol is based on the storeand-forwardprinciple. Packets enteringthe network are stored in a buffer andpassed on in the order of their arrival. Thetransfer over each individual link is monitoredseparately, and an error results in initiationof retransmission on the link. In thisway, correct data transfer is possible evenin networks with heavily disturbed connections.There is one disadvantage, however;the protocol handling requires muchprocessing power, which causes delayand limits the available transfer speed. Today,a typical X.25 network cannot efficientlyutilise link speeds above 64 kbit/s.But the development towards higher transmissionspeed is evident in the X.25 networks,too, and follows the developmentof microprocessor capacity.Due to their limited transmission speed,X.25 networks have not been consideredeffective enough for the interconnection ofLANs in a wide-area environment. Pointto-pointconnections have been preferredwhen high transmission speed has beenthe prime requirement. Although point-topointconfigurations provide the requiredtransmission speed, they are not usuallycost-effective. The reason for this is thatLAN interconnect applications generatedata in the form of bursts; that is, they utilisethe available capacity for very short periodsonly. In fact, the connections are passivemost of the time, resulting in a low degreeof utilisation.Network solutions of today andtomorrowThe new and the traditional, centraliseddatacom environments usually coexist ina company's organisation. Today, manycompanies therefore have a datacom environmentmade up of separate infrastructures.A uniform communications environmentmust be able to meet the needs ofboth LAN-to-LAN connections and of thelarge number of terminals connected tohost computers, Fig. 7.Frame Relay - a newalternative in datacommunicationsThe purpose of introducing Frame Relayis to meet the new requirements, and mainlythose resulting from the development ofLAN-to-LAN communications. The standarddefines a simplified packet switchingservice which meets the need for a simpleFig. 8The Frame Relay standard specifies an interfacebetween a user and a Frame Relay networkERICSSON REVIEW No. 1-2, 1992
Fig. 9A typical Frame Relay network with DTEs, networknodes and public Frame Relay servicesFig. 10Frame Relay networks use permanent virtualconnections, which means that a physical connectioncan provide several logical channels forsimultaneous usedata transmission protocol focusing onhigh speed and requiring a minimum oferror-correcting and flow-controlling functions.The standard, which is described in bothCCITT and ANSI recommendations, definessignal and data transmission at linklevel, OSI level 2, in the interface betweenuser equipment and network, Fig. 8. (Cf.X.25, which comprises the first three OSIlevels and uses a frame at level 2 for thetransmission of a packet at level 3.) Thestandardisation work is briefly described inBox 1.How Frame Relay worksA Frame Relay network is made up of networknodes and user equipment, DTE.s(Date Terminal Equipment) connected tothe network. The DTE, e.g., a personalcomputer, a gateway, a router or a hostcomputer, is provided with the interfacedefined for Frame Relay, Fig. 9.The sending DTE transmits frames to thenetwork. Each of these frames contains anidentification code (Data Link ConnectionIdentifier, DLCI). All network nodes alongthe path to the final destination contain informationindicating the outgoing channelto which a frame with a specific identificationcode is to be sent. The path betweenthe sending and receiving DTEs has beenpredefined by the network operator. Thistype of connection - a Permanent VirtualConnection - is so far the only one definedin the standard. Virtual connections are notincluded in today's Frame Relay function,but future versions of the protocol are expectedto allow such connections too.The network node routes to the right destinationsthe frames sent from a DTE. Thenetwork node reads the identification codeof the incoming frame and sends the frame(without changing it) on the outgoing channelindicated in the node's routing table.This outgoing channel can either be a connectionto another network node (in whichcase the procedure described above is repeated)or a connection directly to the terminatingDTE. However, the way theframes are handled internally in the networkis not defined in the standard.As in X.25 switching, the use of severalidentification codes permits several parallelsessions in different directions to coexiston one physical connection, Fig. 10.In this way, a DTE can communicate simultaneouslywith different destinationsover the same physical connection to thenetwork. This is necessary if the DTE is acommunications port in an LAN, but it is alsoan attractive solution in cases where theDTE is a personal computer or workstationthat uses several simultaneously activewindows.Handling is simple because the protocoldoes not include any error-correctingmechanism. Speeds of several Mbit/s canbe used without requiring unreasonableprocessing capacity for link handling.Today's version of the standard stipulatesa maximum link transmission speed ofERICSSON 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 10 and 11: 8Fig. 11The frame format used for F
- 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
Fig. 7A company's data network should be designedso as to permit both existing <strong>and</strong> future applicationsto use the same physical networkBox 1St<strong>and</strong>ardisation of <strong>Frame</strong> <strong>Relay</strong><strong>Frame</strong> <strong>Relay</strong> as a communications st<strong>and</strong>ard wasfirst proposed by CCITT in the late 80's <strong>and</strong> thenpresented in Recommendation 1.122. At that time,the US st<strong>and</strong>ardisation body ANSI had also beganto take an interest in this field, but the resultof both bodies' work was rather long in coming.Northern Telecom, DEC, CISCO, <strong>and</strong> Stratacomthere<strong>for</strong>e took the matter in their own h<strong>and</strong>s, submittingat the end of 1990 a proposal <strong>for</strong> a st<strong>and</strong>ardbased on the existing - but still incomplete -proposals drawn up by CCITT <strong>and</strong> ANSI. This proposalalso contained a "Local Management Interface",LMI, which describes the exchange of in<strong>for</strong>mationon link status between the DTEs <strong>and</strong>the network. To complete the work <strong>and</strong> <strong>for</strong>ce thepace of st<strong>and</strong>ardisation, <strong>Frame</strong> <strong>Relay</strong> Forum wasestablished in January, 1991.<strong>More</strong> than 70 companies including Ericsson arenow members of <strong>Frame</strong> <strong>Relay</strong> Forum, which doesnot do any st<strong>and</strong>ardisation work of its own but submitsproposals to existing st<strong>and</strong>ardisation bodiessuch as CCITT, ANSI <strong>and</strong> ETSI. The <strong>for</strong>mation of<strong>Frame</strong> <strong>Relay</strong> Forum speeded up the st<strong>and</strong>ardisationwork, <strong>and</strong> the CCITT <strong>and</strong> ANSI st<strong>and</strong>ardshave now reached an appreciable degree of development,including the specification of LMI functionality.CCITT's recommendations include I.223 (whichdescribes the service), Q.922 (describing theframe) <strong>and</strong> 0.933 (signalling). ANSI's versions ofthese st<strong>and</strong>ards, which are basically equivalent tothose specified by CCITT, are called T1.606 (theservice), T1.618 (frame) <strong>and</strong> T1.617 (signalling).(PVC) <strong>and</strong> Virtual Connections (VC). ThePermanent Virtual Connection is a networkpath which is predefined by the networkoperator. The procedure <strong>for</strong> setting up aVirtual Connection includes indication ofthe address by means of a Network TerminalNumber, which is unique to each setof equipment connected. No network operatoris involved in this set-up procedure,which results in the establishment of a networkpath that remains connected until thesender or receiver orders its release.The X.25 protocol is based on the store<strong>and</strong>-<strong>for</strong>wardprinciple. Packets enteringthe network are stored in a buffer <strong>and</strong>passed on in the order of their arrival. Thetransfer over each individual link is monitoredseparately, <strong>and</strong> an error results in initiationof retransmission on the link. In thisway, correct data transfer is possible evenin networks with heavily disturbed connections.There is one disadvantage, however;the protocol h<strong>and</strong>ling requires muchprocessing power, which causes delay<strong>and</strong> limits the available transfer speed. Today,a typical X.25 network cannot efficientlyutilise link speeds above 64 kbit/s.But the development towards higher transmissionspeed is evident in the X.25 networks,too, <strong>and</strong> follows the developmentof microprocessor capacity.Due to their limited transmission speed,X.25 networks have not been consideredeffective enough <strong>for</strong> the interconnection ofLANs in a wide-area environment. Pointto-pointconnections have been preferredwhen high transmission speed has beenthe prime requirement. Although point-topointconfigurations provide the requiredtransmission speed, they are not usuallycost-effective. The reason <strong>for</strong> this is thatLAN interconnect applications generatedata in the <strong>for</strong>m of bursts; that is, they utilisethe available capacity <strong>for</strong> very short periodsonly. In fact, the connections are passivemost of the time, resulting in a low degreeof utilisation.Network solutions of today <strong>and</strong>tomorrowThe new <strong>and</strong> the traditional, centraliseddatacom environments usually coexist ina company's organisation. Today, manycompanies there<strong>for</strong>e have a datacom environmentmade up of separate infrastructures.A uni<strong>for</strong>m communications environmentmust be able to meet the needs ofboth LAN-to-LAN connections <strong>and</strong> of thelarge number of terminals connected tohost computers, Fig. 7.<strong>Frame</strong> <strong>Relay</strong> - a newalternative in datacommunicationsThe purpose of introducing <strong>Frame</strong> <strong>Relay</strong>is to meet the new requirements, <strong>and</strong> mainlythose resulting from the development ofLAN-to-LAN communications. The st<strong>and</strong>arddefines a simplified packet switchingservice which meets the need <strong>for</strong> a simpleFig. 8The <strong>Frame</strong> <strong>Relay</strong> st<strong>and</strong>ard specifies an interfacebetween a user <strong>and</strong> a <strong>Frame</strong> <strong>Relay</strong> networkERICSSON REVIEW No. 1-2, 1992
Change language