








Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
This document delves into the crucial aspects of data link control, a fundamental layer in computer networking. It explores the concepts of framing, flow control, and error control, explaining how these mechanisms ensure reliable data transmission between network nodes. A clear and concise explanation of these concepts, using illustrative examples and diagrams to enhance understanding. It also presents algorithms for sender and receiver protocols, demonstrating the practical implementation of data link control principles.
Typology: Summaries
1 / 14
This page cannot be seen from the preview
Don't miss anything!









Data Link Control The two main functions of the data link layer are data link control and media access control. The first, data link control, deals with the design and procedures for communi- cation between two adjacent nodes: node-to-node communication. We discuss this functionality in this chapter. The second function of the data link layer is media access control, or how to share the link. We discuss this functionality in Chapter 12. Data link control functions include framing, flow and error control, and software- implemented protocols that provide smooth and reliable transmission of frames between nodes. In this chapter, we first discuss framing, or how to organize the bits that are carried by the physical layer. We then discuss flow and error control. A subset of this topic, techniques for error detection and correction, was discussed in Chapter 10. To implement data link control, we need protocols. Each protocol is a set of rules that need to be implemented in software and run by the two nodes involved in data exchange at the data link layer. We discuss five protocols: two for noiseless (ideal) channels and three for noisy (real) channels. Those in the first category are not actually implemented, but provide a foundation for understanding the protocols in the second category. After discussing the five protocol designs, we show how a bit-oriented protocol is actually implemented by using the High-level Data Link Control (HDLC) Protocol as an example. We also discuss a popular byte-oriented protocol, Point-to-Point Protocol (PPP).
Data transmission in the physical layer means moving bits in the form of a signal from the source to the destination. The physical layer provides bit synchronization to ensure that the sender and receiver use the same bit durations and timing. The data link layer, on the other hand, needs to pack bits into frames, so that each frame is distinguishable from another. Our postal system practices a type of framing. The simple act of inserting a letter into an envelope separates one piece of information from another; the envelope serves as the delimiter. In addition, each envelope defines the sender and receiver addresses since the postal system is a many-to-many carrier facility. 307
308 CHAPTER 11 DATA LINK CONTROL Framing in the data link layer separates a message from one source to a destina- tion, or from other messages to other destinations, by adding a sender address and a destination address. The destination address defines where the packet is to go; the sender address helps the recipient acknowledge the receipt. Although the whole message could be packed in one frame, that is not normally done. One reason is that a frame can be very large, making flow and error control very inefficient. When a message is carried in one very large frame, even a single-bit error would require the retransmission of the whole message. When a message is divided into smaller frames, a single-bit error affects only that small frame.
Frames can be of fixed or variable size. In fixed-size framing, there is no need for defin- ing the boundaries of the frames; the size itself can be used as a delimiter. An example of this type of framing is the ATM wide-area network, which uses frames of fixed size called cells. We discuss ATM in Chapter 18.
Our main discussion in this chapter concerns variable-size framing, prevalent in local- area networks. In variable-size framing, we need a way to define the end of the frame and the beginning of the next. Historically, two approaches were used for this purpose: a character-oriented approach and a bit-oriented approach. Character-Oriented Protocols In a character-oriented protocol, data to be carried are 8-bit characters from a coding system such as ASCII (see Appendix A). The header, which normally carries the source and destination addresses and other control information, and the trailer, which carries error detection or error correction redundant bits, are also multiples of 8 bits. To separate one frame from the next, an 8-bit (I-byte) flag is added at the beginning and the end of a frame. The flag, composed of protocol-dependent special characters, signals the start or end of a frame. Figure 11.1 shows the format of a frame in a character-oriented protocol. Figure 11.1 Aframe in a character-oriented protocol Data from upper layer Character-oriented framing was popular when only text was exchanged by the data link layers. The flag could be selected to be any character not used for text communica- tion. Now, however, we send other types of information such as graphs, audio, and video. Any pattern used for the flag could also be part of the information. If this hap- pens, the receiver, when it encounters this pattern in the middle of the data, thinks it has reached the end of the frame. To fix this problem, a byte-stuffing strategy was added to
310 CHAPTER 11 DATA LINK CONTROL Figure 11.3 A frame in a bit-oriented protocol I' Data from upper layer Variable number of bits ' I Header Flag This flag can create the same type of problem we saw in the byte-oriented proto- cols. That is, if the flag pattern appears in the data, we need to somehow inform the receiver that this is not the end of the frame. We do this by stuffing 1 single bit (instead of I byte) to prevent the pattern from looking like a flag. The strategy is called bit stuffing. In bit stuffing, if a 0 and five consecutive I bits are encountered, an extra 0 is added. This extra stuffed bit is eventually removed from the data by the receiver. Note that the extra bit is added after one 0 followed by five 1s regardless of the value of the next bit. This guarantees that the flag field sequence does not inadvertently appear in the frame. Bit stuffing is the process of adding one extra 0 whenever five consecutive 18 follow a 0 in the data, so that the receiver does not mistake the pattern 0111110 for a flag. Figure 11.4 shows bit stuffing at the sender and bit removal at the receiver. Note that even if we have a 0 after five 1 s, we still stuff a O. The 0 will be removed by the receiver. Figure 11.4 Bit stuffing and unstuffing Frame sent I Flag! Header Frame received Data from upper layer 100011111110011111010001 Stuffed t 10001111101100111110010001 Trailer IFlag I Extra 2 bits IFlag 1 Header^10001111101100111110010001 Trailer^1 Flag^ I Unsroffed t I 000 1l11l1100 111110 1000 I Data to upper layer This means that if the flaglike pattern 01111110 appears in the data, it will change to 011111010 (stuffed) and is not mistaken as a flag by the receiver. The real flag 01111110 is not stuffed by the sender and is recognized by the receiver.
SECTION II.3 PROTOCOLS 311 11.2 FLOW AND ERROR CONTROL Data communication requires at least two devices working together, one to send and the other to receive. Even such a basic arrangement requires a great deal of coordination for an intelligible exchange to occur. The most important responsibilities of the data link layer are flow control and error control. Collectively, these functions are known as data link control.
Flow control coordinates the amount of data that can be sent before receiving an acknowl- edgment and is one of the most important duties of the data link layer. In most protocols, flow control is a set of procedures that tells the sender how much data it can transmit before it must wait for an acknowledgment from the receiver. The flow of data must not be allowed to overwhelm the receiver. Any receiving device has a limited speed at which it can process incoming data and a limited amount of memory in which to store incom- ing data. The receiving device must be able to inform the sending device before those limits are reached and to request that the transmitting device send fewer frames or stop temporarily. Incoming data must be checked and processed before they can be used. The rate of such processing is often slower than the rate of transmission. For this reason, each receiving device has a block of memory, called a buffer, reserved for storing incom- ing data until they are processed. If the buffer begins to fill up, the receiver must be able to tell the sender to halt transmission until it is once again able to receive. Flow control refers to a set of procedures used to restrict the amount of data that the sender can send before waiting for acknowledgment.
Error control is both error detection and error correction. It allows the receiver to inform the sender of any frames lost or damaged in transmission and coordinates the retransmission of those frames by the sender. In the data link layer, the term error con- trol refers primarily to methods of error detection and retransmission. Error control in the data link layer is often implemented simply: Any time an error is detected in an exchange, specified frames are retransmitted. This process is called automatic repeat request (ARQ). Error control in the data link layer is based on automatic repeat request, which is the retransmission of data. 11.3 PROTOCOLS Now let us see how the data link layer can combine framing, flow control, and error control to achieve the delivery of data from one node to another. The protocols are normally imple- mented in software by using one of the common programming languages. To make our
SECTION 11.4 NOISELESS CHANNELS 313 sender to receiver. We assume that the receiver can immediately handle any frame it receives with a processing time that is small enough to be negligible. The data link layer of the receiver immediately removes the header from the frame and hands the data packet to its network layer, which can also accept the packet immediately. In other words, the receiver can never be overwhelmed with incoming frames. Design There is no need for flow control in this scheme. The data link layer at the sender site gets data from its network layer, makes a frame out of the data, and sends it. The data link layer at the receiver site receives a frame from its physical layer, extracts data from the frame, and delivers the data to its network layer. The data link layers of the sender and receiver provide transmission services for their network layers. The data link layers use the services provided by their physical layers (such as signaling, multiplexing, and so on) for the physical transmission of bits. Figure 11.6 shows a design. Figure 11.6 The design of the simplest protocol with no flow or error control Sender Receiver Network Data link Physical Get data (^) Delivrdata
I
I Send frame (^) Receive frame Data frames -+-
Network Data link Physical Repeat forever Event: ){otifu:ation from physlclU iaye]" We need to elaborate on the procedure used by both data link layers. The sender site cannot send a frame until its network layer has a data packet to send. The receiver site cannot deliver a data packet to its network layer until a frame arrives. If the protocol is implemented as a procedure, we need to introduce the idea of events in the protocol. The procedure at the sender site is constantly running; there is no action until there is a request from the network layer. The procedure at the receiver site is also constantly rulming, but there is no action until notification from the physical layer arrives. Both procedures are constantly running because they do not know when the corresponding events will occur.
314 CHAPTER 11 DATA LINK CONTROL Algorithms Algorithm 11.1 shows the procedure at the sender site. Algorithm 11.1 Sender-site algorithm for the simplest protocol //Send the frame II Sleep until an event occurs //There is a packet to send GetData()i MakeFrame()i SendFrame()i } WaitForEvent()i if(Event(RequestToSend» { 1 while (true) II Repeat forever 2 { 3 4 5 6 7 8 9 10 } Analysis The algorithm has an infinite loop, which means lines 3 to 9 are repeated forever once the program starts. The algorithm is an event-driven one, which means that it sleeps (line 3) until an event wakes it up (line 4). This means that there may be an undefined span of time between the execution of line 3 and line 4; there is a gap between these actions. When the event, a request from the network layer, occurs, lines 6 though 8 are executed. The program then repeats the loop and again sleeps at line 3 until the next occurrence of the event. We have written pseudocode for the main process. We do not show any details for the modules GetData, Make- Frame, and SendFrame. GetDataO takes a data packet from the network layer, MakeFrameO adds a header and delimiter flags to the data packet to make a frame, and SendFrameO delivers the frame to the physical layer for transmission. Algorithm 11.2 shows the procedure at the receiver site. Algorithm 11.2 Receiver-site algorithm for the simplest protocol / /Deli ver data to network layez ReceiveFrame()i ExtractData()i Del iverData ( ) i } 1 while(true) II Repeat forever 2 { 3 WaitForEvent()i II Sleep until an event occurs 4 if(Event(ArrivalNotification» IIData frame arrived 5 { 6 7 8 9 10 } Analysis This algorithm has the same format as Algorithm 11.1, except that the direction of the frames and data is upward. The event here is the arrival of a data frame. After the event occurs, the data link layer receives the frame from the physical layer using the ReceiveFrameO process, extracts the data from the frame using the ExtractDataO process, and delivers the data to the network layer using the DeliverDataO process. Here, we also have an event-driven algorithm because the algorithm never knows when the data frame will arrive.
316 CHAPTER 11 DATA LINK CONTROL Figure 11.8 Design of Stop-and- Wait Protocol Sender Receiver Network Data link: Physical Deliver Gettata data .. T I .. (^) I I R (^) ecelveI. (^) SendT^ R (^) ecelVeI. (^) Send,T frame frame frame frame Data frame
Network Data link Physical Repeat forever Algorithm 11.3 Sender-site algorithm for Stop-and- Wait Protocol Iwhile (true)
II Sleep until an event occurs AND canSend} II Sleep until an event occurs /1 An ACK has arrived I/Send the data frame I/cannot send until ACK arrives IIRepeat forever IIAllow the first frame to go ReceiveFrame(); I/Receive the ACK canSend true; GetDataO i MakeFrame(); SendFrame()i
} } WaitForEvent()i if (Event (ArrivalNotification) { { WaitForEvent()i if (Event (RequestToSend) { 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 } Analysis Here two events can occur: a request from the network layer or an arrival notifica- tion from the physical layer. The responses to these events must alternate. In other words, after a frame is sent, the algorithm must ignore another network layer request until that frame is
SECTION 1I.4 NOISELESS CHANNELS 317 acknowledged. We know that two arrival events cannot happen one after another because the channel is error-free and does not duplicate the frames. The requests from the network layer, however, may happen one after another without an arrival event in between. We need somehow to prevent the immediate sending of the data frame. Although there are several methods, we have used a simple canSend variable that can either be true or false. When a frame is sent, the variable is set to false to indicate that a new network request cannot be sent until canSend is true. When an ACK is received, canSend is set to true to allow the sending of the next frame. Algorithm 11.4 shows the procedure at the receiver site. Algorithm 11.4 Receiver-site algorithm for Stop-and- Wait Protocol WaitForEvent(); II Sleep until an event occurf if(Event(ArrivalNotification)} IIData frame arrives { /IDeliver data to network layex IISend an ACK frame IIRepeat forever ReceiveFrame(}; ExtractData(}i Deliver(data}; SendFrame(); } 1 while (true) 2 { 3 4 5 6 7 8 9 10 11 } Analysis This is very similar to Algorithm 11.2 with one exception. After the data frame arrives, the receiver sends an ACK frame (line 9) to acknowledge the receipt and allow the sender to send the next frame. Example 11. Figure 11.9 shows an example of communication using this protocol. It is still very simple. The sender sends one frame and waits for feedback from the receiver. When the ACK arrives, the sender sends the next frame. Note that sending two frames in the protocol involves the sender in four events and the receiver in two events. Figure 11.9 Flow diagramfor Example 1I. Sender INA] Receiver rIJ Arrival Frame Arrival : I Request I : Arrival I
Time Time
SECTION 11.5 NOISY CHANNELS 319 communication. The sequence numbers of course can wrap around. For example, if we decide that the field is m bits long, the sequence numbers start from 0, go to 2 m^ - 1, and then are repeated. Let us reason out the range of sequence numbers we need. Assume we have used x as a sequence number; we only need to use x + 1 after that. There is no need for x + 2. To show this, assume that the sender has sent the frame numbered x. Three things can happen.
are acknowledged and there is no ambiguity at either site. In cases 2 and 3, the new frame is x + I, not x + 2. If only x and x + 1 are needed, we can let x = 0 and x + I == 1. This means that the sequence is 0, I, 0, I, 0, and so on. Is this pattern familiar? This is modulo- arithmetic as we saw in Chapter 10. In Stop-and-Wait we use sequence numbers to number the frames. The sequence numbers are based on modul0-2 arithmetic. Acknowledgment Numbers Since the sequence numbers must be suitable for both data frames and ACK frames, we use this convention: The acknowledgment numbers always announce the sequence number of the next frame expected by the receiver. For example, if frame 0 has arrived safe and sound, the receiver sends an ACK frame with acknowledgment 1 (meaning frame 1 is expected next). If frame 1 has arrived safe and sound, the receiver sends an ACK frame with acknowledgment 0 (meaning frame 0 is expected). In the acknowledgment number always announces in modul0-2 arithmetic the sequence number of the next frame expected. Design Figure 11.10 shows the design of the Stop-and-Wait ARQ Protocol. The sending device keeps a copy of the last frame transmitted until it receives an acknowledgment for that frame. A data frames uses a seqNo (sequence number); an ACK frame uses an ackNo (acknowledgment number). The sender has a control variable, which we call Sn (sender, next frame to send), that holds the sequence number for the next frame to be sent (0 or 1).
320 CHAPTER 11 DATA LINK CONTROL Figure 11.10 Design ofthe Stop-and-WaitARQ Protocol SII Next frame
0 send r---r--- ---r---, '0'101'0'L _ __ 1 J··· Sender Receiver Network Data link Physical Data frame ACKframe (^) Deliver
I ...^ I R (^) ecelveI. (^) SendT^ R (^) ecelveI. (^) SendT frame frame frame^ frame
Network Data link Physical
network layer I
. - - ,.C; for sender'site .-^ Time-out I ..;._,,,:,,:,,'.:" , (^) Event: 1..
E (^) ven.t: INotificationphysical layer from I Repeat forever ." .'
1..
P ySlC ayer The receiver has a control variable, which we call Rn (receiver, next frame expected), that holds the number of the next frame expected. When a frame is sent, the value of Sn is incremented (modulo-2), which means if it is 0, it becomes 1 and vice versa. When a frame is received, the value of Rn is incremented (modulo-2), which means if it is 0, it becomes 1 and vice versa. Three events can happen at the sender site; one event can happen at the receiver site. Variable Sn points to the slot that matches the sequence number of the frame that has been sent, but not acknowledged; Rn points to the slot that matches the sequence number of the expected frame. Algorithms Algorithm 11.5 is for the sender site. Algorithm 11.5 Sender-site algorithm for Stop-and- Wait ARQ WaitForEvent(); 1 n = 0; 2 anSend = true; 3 hile (true) 4 { 5 II Frame 0 should be sent first II Allow the first request to go II Repeat forever II Sleep until an event occurs