3 Frame Relay Systems should be as simple as possible but not simpler Albert Einstein Many people are familiar with the first widely used service of the datacomms era—X.25. As a mature product of the ‘analogue era’, it is a complex protocol. Much of this complexity arose from the need to protect against errors introduced by noisy analogue transmission circuits and the comparatively long round-trip delay caused by their low transmission speeds. Frame Relay, by contrast, is very much a product of the ‘digital age’, exploiting the much lower error rates and higher transmission speeds of modern digital systems. In particular, Frame Relay has its roots in the Integrated Services Digital Network, the ISDN (Griffiths 1992). 3.1 THE ISDN The ISDN is the latest step in the evolution of the PSTN. The early 1970s saw the widespread introduction of digital transmission into the telephone network. This was followed in the late 1970s by digital switching systems with computer control of switching operations together with powerful message-based inter-processor signalling between the switching centres. This combination of digital switching and digital transmission systems—the so-called Integrated Digital Network or IDN—promised great flexibility for new service innovation and reductions in operating costs. But the local access circuit between the user and the local exchange was still analogue. It was still just a telephone network. Driven by the increasing importance of non-voice services, the 1980s saw the next logical step in the evolution of the telephone network in which the digital connection is taken all the way to the user making it equally suitable for voice and non-voice services. To exploit the power of this all-digital Total Area Networking: ATM, IP, Frame Relay and SMDS Explained. Second Edition John Atkins and Mark Norris Copyright © 1995, 1999 John Wiley & Sons Ltd Print ISBN 0-471-98464-7 Online ISBN 0-470-84153-2 . Figure 3.1 Separation of user information and signalling in the ISDN network the message-based signalling was similarly extended all the way to the user. This development creates the Integrated Services Digital Network, the ISDN. As Figure 3.1 shows, one of the distinctive features of the ISDN is that the user information and signalling are kept logically separate from end-to-end through the network. In ISDN parlance, the user’s information lies in the user-plane (U-plane) and the signalling lies in the control-plane (C-plane). It can be seen that in effect the ISDN is composed of two sub-nets, a switched information sub-net (above the dotted line) and a signalling sub-net (below the dotted line). The signalling protocols are layered in accordance with the OSI reference model. There is a network layer call control protocol, specified in ITU-T standard Q.931, which defines the call control messages and procedures (types, formats, meanings, interactions and so on). There is also a link layer protocol, defined in Q.921, which makes sure that the call control messages are reliably passed, without errors, between the terminal and the call control process in the serving local switch. Basically the call set-up procedure illustrated in Figure 3.2 is as follows. A terminal initiates a call by creating a SETUP message and sending it to the serving local switch. This message contains the calling and called line addresses, as E.164 numbers, together with any other information needed to establish an appropriate connection such as terminal compatibility information; there is no point in trying to set up a connection between a fax machine and a telephone, for example! After performing the usual validity checks (does the SETUP message contain all the information needed for call establishment? was the last bill paid in time?, etc.) the local switch acknowledges receipt of the SETUP message by returning a CALL PROCEEDING message that indicates that the call is now being set up. It then routes the SETUP message to the next 44 FRAME RELAY . Figure 3.2 Basic call control using ISDN signalling exchange en route until it reaches the destination local switch, where it is passed to the called terminal. On receipt of the SETUP message the called terminal may accept the call by returning a CONNECT message as shown, causing the switch cross-points to be switched en route. Finally the destination local exchange sends a CONNECT ACKnowledge message to the called terminal, indicating which of the available channels will carry the call. The call enters the ‘conversation’ phase. At some later time a corresponding exchange of signalling messages clears the call as shown. For a more comprehensive and rigorous account of all aspects of the ISDN the reader is referred to the companion volume ISDN Explained (Griffiths 1992). As a development of the PSTN, the ISDN is intrinsically circuit-switched. But for many data applications packet-switching is clearly more appropriate. X.25, however, does not fit the ISDN model of keeping user information and signalling separate. Nor is it necessary to include X.25’s heavyweight error correction protocols in the comparatively error-free digital environment. Something else was clearly needed in the ISDN to support data services effectively and Frame Relay was defined to fill this gap. 3.2 FRAME RELAY AS AN ISDN BEARER SERVICE Frame Relay is a simple connection-oriented, virtual circuit packet service. It provides both switched virtual connections (SVCs) and permanent virtual 453.2 FRAME RELAY AS AN ISDN BEARER SERVICE . Figure 3.3 ISDN Frame Relay circuits (PVCs), and it follows the ISDN principle of keeping user data and signalling separate. An ISDN Frame Relay SVC would be set up in exactly the same way as an ordinary circuit-mode connection using ISDN common-channel signalling protocols as outlined above. The difference is that in the data transfer, or ‘conversation’, phase the user’s information is switched through simple packet switches (known as frame relays) as shown in Figure 3.3, rather than circuit-mode cross-points. PVCs would of course be set up on subscription by the network operator; user signalling is neither needed nor provided. To cover the additional call parameters and procedures needed for frame mode services, an enhanced version of Q.931 (the call control signalling protocol) has been defined, known as Q.933. The Frame Relay data transfer protocol In Frame Relay information is transferred in variable-length frames with the simple format shown in Figure 3.4. In addition to the user’s information there is a header and trailer, each of two octets. 1 The header contains a ten-bit label agreed between the terminal and the network at call set-up time (or at subscription time if a PVC) which uniquely identifies the virtual call. This label is known as the Data Link Connection Identifier (DLCI). Terminals can therefore support many simultaneous virtual calls to different destinations, or even a mixture of SVCs and PVCs, using theDLCIto 1 The header is normally of two octets, but the standards allow for three and four octet headers which can accommodate longer labels. 46 FRAME RELAY . Figure 3.4 Format of Frame Relay frame identify which virtual connection each frame belongs to. DLCI values 16 to 991 are available to identify the user’s SVCs and PVCs. Other DLCI values are reserved for specific purposes. For example, DLCI = 0 is used to carry call-control signalling, and DLCIs 992 to 1007 are used to carry link layer management information as described below. HDLC flags (the bit pattern 01111110) are used to indicate the beginning and end of each frame and as interframe channel fill, with zero-bit insertion and deletion used to avoid flag simulation in the user information field. This is exactly as in X.25. The minimum amount of user information that a frame may contain is one octet, and the default maximum size of the information field is 260 octets. However, most implementations support up to 1600 octets to minimise the need to segment and reassemble LAN packets for transport over a Frame Relay network. The trailer contains a two-octet Frame Check Sequence (FCS) calculated in the same way as for an X.25 frame. The EA bit indicates address extension and follows standard HDLC practice. Set to 0 it means that another octet of address follows this one. Set to 1 it means that this is the last octet of the address. C/R, the command/response bit, is passed transparently from one terminal to the other. A link layer protocol has been defined for frame mode bearer services. Usually referred to as LAPF or Q.922, it is based on Q.921 the link layer protocol used to carry user signalling (see Figure 3.1). The data transfer protocol used in Frame Relaying is a (small) subset of LAPF, known as the data link core protocol. The LAPF core protocol provides for the sequence-preserving bi-directional transport of frames between terminals. It includes the detection of frame errors, but not error correction. Nor does the network operate flow control. It is left to the higher-layer protocols operating directly between the terminals to look after error correction and flow control. There is thus very little processing of frames by the network nodes, and frames can pass through the network quickly and transparently. Figure 3.5 illustrates how simple the Frame Relay data transfer protocol really is. Consider that we have a Frame Relay terminal connected to port x and that we have a single virtual connection established. Remember that at call set-up time (or at subscription time if a PVC) we agreed that we would 473.2 FRAME RELAY AS AN ISDN BEARER SERVICE . Figure 3.5 The principle of Frame Relaying use a particular 10-bit label (DLCI) with the network. This is shown as a. The terminal sends a sequence of frames into the network. Figure 3.5 shows one of them: it contains DLCI = a in the header. When the Frame Relay switch receives this frame it does a few checks. Firstly it looks for transmission errors using the 2-octet frame check sequence (FCS) contained in the trailer. If the frame has any transmission errors it is simply discarded. If not, a few other checks are done: is the frame too long? too short? has the DLCI = a been allocated? Again, if an error is found the frame is simply discarded. Assuming that the frame gets through these checks, the FrameRelay switch then looks in the routing look-up table to see which outgoing link it should be transmitted on. Looking down the routing table for port x the switch finds that frames with DLCI = a should be routed out on port y and should be given the new label DLCI = b on the outgoing link. Because the DLCI is changed it is necessary to recalculate the frame check sequence before transmitting the frame. At call set-up time entries in routing look-up tables were made in all Frame Relay switches en route, exactly like that shown. So our frame passes through the network until it is finally passed to the destination terminal, taking a different value for the DLCI for each link on the way. Figure 3.5 shows only one direction of transmission. Transmission in the other direction is achieved in exactly the same way. Indeed, as we will see, one of the merits of Frame Relay is that the two directions of transmission are treated independently and can be configured to have different throughput. If we should want to set up additional virtual connections they would be given differentDLCIsandtheswitcheswouldprocessandroutethemindependently. The above illustration of the Frame Relay principle is intended to give a clear description of the data transfer protocol. The reader should realise that real network implementations may actually be quite different to the picture 48 FRAME RELAY . Figure 3.6 The Frame Relay protocol stack painted here. We will see in Chapter 5 for example that an ATM network can support the Frame Relay service very effectively;and in practice implementa- tions include functionality not mentioned here, such as the ability to dynamicallyreconfigure routing tables to route around link or switch failures. But the illustration shows several things. Firstly, DLCIs have only ‘local’ significance. They will in general be different at each end of a virtual connection; if they are the same it is just coincidence. Secondly, the network does not operate any flow control (we will see later, however, that restrictions are placed on the rate at which a terminal may send frames). Thirdly, the network does not attempt to correct any errors it may find. Error correction and flow control are left to higher-layer protocols operating end-to-end between the terminals. Summarising then, the data transfer protocol used in Frame Relay (the LAPF core protocol) does the following things • identifies the beginnings and ends of frames using HDLC flags • uses zero bit insertion and extraction to prevent the flag sequence being simulated within a frame • detects transmission errors using the frame check sequence • checks that frame length and, where possible, parameters in frames are valid • multiplexing and demultiplexing frames for different virtual connections using the DLCIs • congestion control (we will see something of how this is done in the next section). Very few protocols can be described so succinctly! The Frame Relay protocol stack (Figure 3.6) shows the data link layer protocol divided into the data link core sublayer and the data link control sublayer. (For simplicity signalling is omitted). The Frame Relay service is concerned only with the core sublayer. Users may choose any Control sublayer they wish, providing that it is compatible with the Q.922 core sublayer, including of course the Q.922 control sublayer. 493.2 FRAME RELAY AS AN ISDN BEARER SERVICE . Congestion One of the great merits of the simple data transfer protocol is that it provides a high degree of transparency to the higher-layer protocols that are carried. This contrasts with X.25, where the scope for destructive interference with higher layer protocols often causes problems and can seriously impair performance and throughput. But simplicity has its price. The absence of flow control leaves the network open to congestion. Congestion ultimately means throwing frames, away. Throwing frames away causes higher layer protocols to retransmit lost frames, which further feeds the congestion, leading to the possible collapse of the network. Congestion management is therefore an important issue for the network designer and network operatorif these serious congestion effects are to be controlled and, preferably, avoided. Congestion management includes dimensioning the network so that it can carry the expected traffic. It also includes implementing real-time controls in the network, which attempt to minimise the likelihood of congestion arising, recover gracefully from any congestion that does actually occur, and spread the effects of any congestion ‘fairly’ over all affected users. It would clearly be unfair, for example, to penalise users who are keeping within their agreed traffic profiles (see below), at the expense of more profligate users who are not. Congestion management is not standardised. It is left to the network operators and differs from one network to another, depending on the capabilities and features designed into the switches, the network topology and dimensioning rules used, the services actually delivered to users, the control the network operator has over the CPE, and so on. But the standards do include mechanisms for indicating the onset of congestion and guidance on how CPE should respond to such notification. Looking at the frame header in more detail (Figure 3.4), we can see that two of the bits, designated the forward explicit congestion notification (FECN) and backward explicit congestion notification (BECN) bits, are used to carry congestion indications to users’ terminals. When the onset of congestion is detected by a frame relay switch, typically by a transmission queue length exceeding a preset threshold,it sets the FECN and BECN bits in theheaders of any frames currently passing through the switch. As shown in Figure 3.7, the FECN bit is set in frames goingtowards the receiving terminal which can then use higher-layer protocols to make the transmitting terminal reduce its sending rate, typically by reducing a window size. The BECN bit is set in frames going back to the sending terminal, and achieves the same effect more directly. Alternatively, a congested switch can send congestion notification to switches at the edge of the network ‘in bulk’ using something called a consolidated link layer management (CLLM) message. The CLLM message is sent on a Layer 2 management connection (DLCI = 1007) and contains a list of the DLCIs of virtual connections that are currently affected by congestion. The edge node can then take appropriate action to temporarily throttle the input of frames to the network, using either FECN/BECN or further CLLM 50 FRAME RELAY . Figure 3.7 FECN and BECN indicate congestion messages to notify congestion to the relevant terminals. In addition to these explicit indications of congestion the terminal can, of course, sense congestion from the loss of frames or a significant increase in cross-network delay. This is sometimes referred to as ‘implicit’ congestion notification. It is clearly desirable for terminals to co-operate in controlling congestion by reducing their demands on the network when notified of congestion, either explicitly or implicitly, and standards have defined procedures that should be used for this (I.370). But for obvious reasons the network cannot rely entirely on users actively co-operating in this, and must include congestion control mechanisms that prevent catastrophic collapse of the network. In addition to the explicit congestion notification bits, a third bit, designated the discard eligible (DE) bit, can be set either by the user or the network to indicate that the associated frame should, in the event of congestion, be discarded in preference to frames in which the DE bit is not set. We will see the DE bit again. Quality of service—what the customer actually gets It is important for the users and the network operator to agree on the nature and quality of the service to be provided. This gives the service provider an estimate of the traffic to be expected, essential to dimension the network properly, and it gives users defined levels of service which they can select from to best match their requirements. It also gives users defined expectations against which they can complain if the service actually achieved falls short. The Frame Relay standards specify more than a dozen parameters which characterise service quality, some relating to the demand the user will place on the network, others specifying the performance targets the network operator is expected to meet. The key parameters that characterise the Frame Relay service are the 513.2 FRAME RELAY AS AN ISDN BEARER SERVICE . Figure 3.8 Frame Relay service parameters committed information rate (CIR), sometimes also known as throughput, the committed burst size (B c ), and the excess burst size (B e ), all defined in relation to an averagingperiod T c , normally calculated as B c /CIR. They are negotiated at call set-up time in the SETUP message requesting the connection (or set at subscription time for a PVC). The relationship between them is illustrated in Figure 3.8. The precise meanings of these parameters is open to a bit of interpretation. But B c is usually regarded as the maximum amount of data the network is prepared to accept during T c with any real guarantee of delivery; CIR is the corresponding data rate. B e is usually taken to indicate the maximum amount of data during an interval T c , over and above B c , that the network will accept: this ‘excess’ data is usually carried on a ‘best efforts’ basis. These service parameters are policed at the point of entry to the network, and they can be set independently for each direction of transmission to cater efficiently for applications that send more information in one direction than the other, such as interactive screen-based applications. Figure 3.8 illustrates three regions of operation, shown as ‘guaranteed’, ‘discard eligible’, and ‘discard on entry’. In the ‘guaranteed’ region (i.e. for frames 1 and 2) the network operator aims to offer a high level of assurance that frames will be delivered and dimensions the network accordingly. In the ‘discard eligible’ region the network will accept the traffic (i.e. frame 3) but set the DE bit: in the (hopefully unlikely) event that congestion is encountered this frame will be discarded before frames in which the DE bit is not set. In the ‘discard on entry’ region the frames are discarded on entry as a means of protecting the network from traffic levels likely to cause congestion. In practice CIR on a 2048 kbit/s access circuit would typically be selectable up to a maximum of 1024 kbit/s for each virtual connection in steps of 16 kbit/s. It can be seen that these parameters can be varied to achieve a very wide range of service levels. A typical example would be a ‘committed’ or ‘assured’ service in which network resources are strictly dimensioned, or even reserved, on the basis of the CIRs. This would give a very low probability of frame loss, provided the user did not significantly exceed his contracted CIR. Such a service could even be used to emulate a real circuit in order to carry, for 52 FRAME RELAY .