Data Link Control (DLC) Protocols

Transcription

1 Data Link Control (DLC) Protocols The purpose of a MAC protocol is to let competing computers access a shared medium so that a computer can transmit a data frame to another computer possibly without collision. However, we need to understand the following limitations of MAC protocols: - Packet loss: This can happen due to a MAC layer dropping a packet after failing several retrials. Packet loss can occur due to errors in the medium. Also, a receiver can drop a correctly received packet if the upper layer protocol temporarily runs out of buffer. - Duplicate packets: A receiver can receive multiple copies of the same packet. This can happen due to possible retransmissions occurring at the MAC level. - Unacknowledged data transmission: In case of Ethernet, data frames are not acknowledged at the MAC level. Thus, a sender has no idea if a data frame has been correctly delivered or not. MAC protocols are insensitive to the following two factors: - processing speed of the receiver, and - availability of buffer at the receiver. For example, if a faster router transmits data at a higher rate than the processing speed of another router, the second router will start dropping data packets because of lack of buffer space. Therefore, two computers need to exchange data at a controlled rate determined by their individual speeds and buffer sizes. If two computers user computers or routers communicate for a while, a data link is assumed to exist between the two for that period. The data link may appear on top of a shared medium, say, Ethernet or wireless medium, or a dedicated medium, say, a fiber link connecting two routers. The idea of a data link in different scenarios has been illustrated in Figure D1. A DLC protocol provides a layer of abstraction on top of the MAC protocol to provide better quality of service to its upper layer, namely, the routing protocol, as illustrated in Figure D2. Ideally, we want to achieve the following in a reliable DLC protocol. - The sender gets a confirmation that each and every packet has been correctly delivered to the receiver. - At the receiving end, the user of the DLC protocol gets exactly one copy of each new data packet transmitted by the user of DLC at the sending end. - Packet flow between sender and receiver is regulated by considering their own processing speeds and buffer sizes. 1

2 Note: Though it is desirable to have an ideal DLC protocol, sometimes it is neither achievable nor desirable to satisfy the ideal conditions. Lack of desirability is due to the fact that in certain situations it is more desirable to achieve the ideal condition in another layer of protocol, where it is less expensive to do so. Thus, we can have several DLC protocols delivering data with differing quality levels, as illustrated in Figure D3. Computer (Client) Data Link Computer (Server) Shared medium LAN Router Data Link Router Dedicated physical link Data Link Air interface Base station Cell phone Figure D1: The idea of data link used in different scenarios. 2

3 User User DLC MAC PHY Reliable view Unreliable Physical Medium DLC MAC PHY Figure D2: The DLC layer providing a reliable abstraction of the underlying unreliable layers. User of DLC User of DLC DLC1 DLC2 DLC3 DLC1 DLC2 DLC3 MAC MAC Physical Medium + PHY layer Figure D3: Co-existence of multiple DLC protocols. In the following, we will discuss a variety of DLC protocols with differing capabilities. A very simple DLC protocol without acknowledgement A simple DLC protocol without acknowledgement has been shown in Figure D4. In this protocol, when a user (upper layer protocol) makes a request to a DLC entity to send a packet, the DLC protocol simply make a send request to the underlying MAC. It is possible that retransmissions and acknowledgements (in a WLAN) occur at the MAC level, but there are no retransmissions and ACK at the DLC level. The DLC protocol 3

4 makes a send request exactly once to the underlying MAC. The underlying MAC makes an effort to deliver the packet to the destination, but it may fail to do so, and it may deliver multiple copies of the data packet to the receiver DLC protocol. Thus, the main drawbacks of this protocol are as follow: - A receiver DLC may not receive a data packet sent by the sender DLC. This is possible because there is no more protocol actions at the DLC level, such as ACK and retransmission. Packet loss is possible due to the fact that the MAC layer may fail to deliver the packet. - Due to retransmissions occurring at the MAC level and due to the absence of a mechanism to filter out duplicate packets at the DLC level, the DLC user at the receiver s end may receive multiple copies of the same packet. - The user of a DLC entity at the sender s end does not get a confirmation that the packet has been correctly delivered to the receiver. Request to Transmit DATA from user of DLC Sender DLC Send(DATA) Receiver DLC Request to Transmit DATA from user of DLC Send(DATA) DATA to user of DLC DATA to user of DLC Time Figure D4: A very simple DLC protocol without ACK In some applications, in spite of the drawbacks of the simple DLC protocol of Figure D4, we use the protocol for two reasons as explained below. - We can not do anything better. In some applications, there is no time left to perform additional operations, such as sending an ACK and retransmitting a packet if an ACK is lost. The application just hopes that the packet gets to the other side. If the other side does not receive the packet, no great damage is expected to be done and the user at the receiver s end recovers from the situation caused by the loss of packet after a long time. 4

5 - We do not have to do anything better. We take this view if the occurrences of the drawbacks are rare and hope that an upper layer protocol, such as TCP, circumvents the drawbacks. In order to eliminate some of the drawbacks of the protocol shown in Figure D4, we present a slightly different DLC protocol with an ACK mechanism in the following. A connectionless DLC protocol with acknowledgement In Figure D5, we present a DLC protocol using acknowledgements. In this case, the sender DLC requests the underlying (not shown in the figure) MAC to send a DLC data packet and starts a timer. If the receiver DLC correctly receives the data packet, it gives the data to its (upper layer) user, and sends back an ACK to the sender. If the sender DLC gets a timeout before receiving an ACK, it makes another request to the MAC to send the data. Thus, the sender DLC gets a confirmation if the data is delivered to the user at the receiver DLC end. A request to the MAC to re-send the data packet may cause the receiver to receive multiple copies of the data packet. Also, any retransmission by the MAC layer may also cause the receiver DLC to receive multiple copies of the DLC data packet. Note: The ACK packet seen in Figure D5 is different from any ACK frames used by the MAC layer in WLAN. An ACK packet in the DLC protocol is treated as a data packet by the MAC layer, because the MAC layer does not interpret the header of a packet received by it from the DLC layer. Request to Transmit DATA from user of DLC Sender DLC Send(DATA) Receiver DLC Optional notification to user of DLC Time Send(ACK) [No ACK: Retransmit] Send(DATA) DATA to user of DLC DATA to user of DLC Figure D5: A DLC protocol with ACK In this protocol, the sender DLC gets a conformation of the receipt of data packets by the receiver DLC and packet loss is handled by using retransmission mechanism. However, the receiver may still receive duplicate packets. Handling of duplicate packets may be left to an upper layer protocol, such as the TCP. 5

6 A classical design consideration Because of the unreliable nature of MAC protocols, we build additional functionalities to address packet loss and filtering out duplicate packets into upper level protocols, such as DLC and TCP. A classical question: In what protocol layer we should detect packet loss and filter out duplicates? To answer this question, we need to consider the quality of the physical medium and the tolerance level of applications as far as packet loss and duplicates are concerned. - If we are using a very reliable medium where bit error is rare and far between, any attempt to handle packet loss and detect duplicates at the DLC level will simply add delay to packet delivery. This is because, if the sender expects an ACK for every packet, or, even a block of packets, transmitted by it self, it is going to initiate a timer and wait for an ACK to arrive. This timer mechanism will cause packet transmission to be delayed. Thus, if packet loss is rare and far between, it is better to leave the task of handling packet loss and duplicate detection to TCP. - If we are using an unreliable medium where bit error is high, it is better to detect packet loss and duplicates at the DLC level. In fact, because of the high BER in wireless channels, the IEEE MAC protocol uses an ACK mechanism to detect packet loss at the MAC level. With a high BER medium, if we leave the concerns of packet loss and duplicate detection to the TCP layer, then it becomes too inefficient to do so. To illustrate this point, let us consider the following example. Let TCP be transmitting packets of 10 Kbytes length, and let MAC frames be limited to 1 Kbytes. Thus, somewhere the long TCP packets are fragmented into ten smaller packets so that each can fit in a 1-Kbyte MAC packet. Assume that one out of the ten smaller packets is lost at the MAC level. Thus, the receiver TCP will see a hole in its 10 Kbytes packet, and ask the sender TCP to retransmit the entire packet even though only a small part of the larger packet was missing. If packet loss had been handled at the DLC level, retransmission at the TCP level would have been avoided. 6

7 A reliable DLC protocol--the Automatic Repeat request (ARQ) protocol In the following, we discuss a reliable DLC protocol, commonly known as the ARQ (Automatic Repeat request) protocol. This protocol has the following desirable features: - The sender of a data packet gets a conformation that the receiver has received the packet. This is achieved by having an ACK mechanism in the protocol. Not having received an ACK for a (new) packet allows us to retransmit the packet by associating a timer with the ACK. - The receiver delivers (at most) one copy of the sender s (new) packet to its upper layer. (The idea of at most comes into picture because there is a certain probability that the MAC layer may fail to deliver any packet to the packet s destination MAC.) The idea of delivering one copy of each new data packet implies that there is a need for distinguishing retransmitted packets from a new one. This is achieved by having a sequence number field in the packet header. A 1-bit sequence number is good enough for this purpose. Informal description of the ARQ protocol - At each instant of time, the receiver expects to receive a particular sequence number next. Any arriving packet with a wrong sequence number is rejected. - A packet with the expected sequence number is delivered to the user. - The expected sequence number is (incremented by 1) modulo 2. - The sender waits for a positive ACK before advancing to the next packet. The desired ACK tells the sender to transmit the next packet. Hence, the protocol is Automatic Repeat request. We present the formal behavior of the ARQ protocol in Figures D6 and D7. Figure D6 gives the sender s behavior in SDL (Specification and Description Language), and Figure D7 gives the receiver s behavior in SDL. Note: SDL is an internationally standardized language for specification and description of distributed systems. This language was developed and standardized by the telephone industry in the mid-70s. Communication protocols these days are commonly specified in SDL. Protocol behaviors are specified as communicating processes in SDL, where a process is an extension of the well-known finite-state machine (FSM) notation. A DLC packet in the ARQ protocol contains a sequence number field. The sequence number field is 1-bit long, and, thus, it can take up two distinct values, namely, 0 and 1. At any instant of time, the receiver expects to receive a packet with a certain sequence number. All packets with the other sequence number are considered to be duplicates of the original, expected packet. It is important to have a sequence number field to distinguish a new packet from old ones. 7

8 Start NTFS = 0 IDLE data from Network layer Construct packet p = (NFTS, data) Send p to MAC Start a timer WAIT ACK(seq) Timeout No seq == NFTS Yes NFTS: Next Frame To Send NFTS++ mod 2 Stop timer. 8

9 Figure D6: ARQ Protocol (Sender s behavior in SDL Specification and Description Language) Start NTFR = 0 IDLE Packet p = (seq, data) from MAC Yes NFTR = = seq No Send data to Network layer above NFTR++ mod 2 Construct an ACK packet p = ACK(nseq), where nseq = 1 - NFTR NFTR: Next Frame To Receive Send p to MAC 9

10 Figure D7: ARQ Protocol (Receiver s behavior in SDL Specification and Description Language) Drawback of the ARQ protocol In the ARQ protocol, the sender transmits the next data packet after receiving an ACK for its previous data packet. Thus, the sender needs to wait for an ACK to arrive from the receiver before it can transmit the next data frame. This waiting time causes the protocol to be very inefficient under certain conditions as explained below. Computer A Computer B Request from upper layer Data ACK Figure D8: A satellite link connecting two computers. Consider the interconnection of two computers by a satellite link as shown in Figure D8. Let the speed of the satellite link be 50 Kilobits per second (Kbps). Let the round-trip delay between the two computers via the satellite be 500 ms. Let the data packet length be 1 Kbps. We assume that ACK packets are very small size. At t = 0, computer A receives a request to transmit a packet to computer B. Let A initiate the transmission right away at t = 0. A will continue transmitting until t = 20. The packet will take 250 ms to reach B. Thus, B will receive the complete packet at t = = 270. Next, B will respond by sending a small ACK packet. The ACK packet will arrive at A at t = = 520. The sender was busy transmitting the packet for 20 ms out of the total time of 520 ms. Thus,, we can compute the percentage of time for which A was blocked as follow: (520 20)/520 = 96%. Thus, 96% of the time computer A remains idle. 10

11 Note: The above kind of inefficiency of the ARQ protocol occurs when we have long transit time and high bandwidth. Short packets also cause inefficiency. Sliding Window Protocol The drawback of the ARQ protocol is that the sender must wait for an ACK to come from the receiver before it can send the next data packet. Thus, the sender can not send multiple data packets before waiting for an ACK. The motivation in the design of a sliding window protocol is to allow a sender to send multiple data packets before it waits for an ACK packet. The sender maintains an important data structure, called a Send Window (SW), with the following interpretation: - A send window is the set of sequence numbers corresponding to packets the sender is permitted to send. - These packets have been sent or can be sent, but are as yet not acknowledged. The normal behavior of the sender is as follows (How the sender behaves when there is an error will be explained in a later part.): - All data packets are numbered using a sequence number field of n bits. Thus, data packets are numbered between 0 and 2 n -1. The SW is smaller than the sequence number space so that when the sequence number space wraps around, it is still possible to distinguish a new copy of a packet with a certain sequence number from old data packets with the same sequence number. - If the sender receives a data packet from its user the network layer above itself it processes the packet as follows: o If the SW is not full, the sender prepares a new data packet by including the appropriate sequence number, saves a copy of the new packet, transmits the new data packet, and starts a timer. (For the goback-n error handling mechanism, the sender maintains just one timer corresponding to the oldest unacked packet.) o If the SW is full and there is no space available to buffer the data packet, a notification can be given to the (upper) network layer that the packet could not be transmitted, or the network layer can be blocked by not returning control to the caller. o If the SW is full, but there is space to buffer the data packet, then create a new data packet with the next sequence number and simply buffer the packet. 11

12 - If the sender receives an ACK corresponding to the lower-edge of the SW, i.e., the first packet in the send window, the buffer space for the entry is emptied and the window is advanced by 1. This may cause the sender to transmit a new packet the one at the end of the SW, if one exists. - If the sender receives an ACK for a packet within the send window, but it does not correspond to the one at the lower-edge of the window, then all packets from the start of the send window up to and including the ACKed packet are considered to be acknowledged, and the send window is advanced accordingly. This idea is called block acknowledgement an ACK for one packet implicitly represents acknowledgements for more than one packet. This is possible because the receiver is assumed to send an ACK for each data packet delivered to the network layer. - (For a received ACK, in case of Go-back-N, the timer is restarted for the oldest unacked packet.) Let us take an example. Let the lower-edge of the send window correspond to sequence number 5, the window size is 4, and all the four packets have been transmitted. If the sender receives an ACK for sequence number 7, then data packets with sequence numbers 5, 6, and 7 are considered to be ACKed. Next, the send window is advanced by three, thus, making the window cover sequence numbers 8 through 11, and three more data packets can be transmitted by the sender. Note: Handling of a timeout will be explained in a later part of these notes. The normal behavior of the receiver is explained as follows. The error situation will be explained separately. - For consistency reason, a similar sequence numbering mechanism is also used by the receiver, i.e., packets are numbered using an n-bit field. - The receiver also maintains an important data structure, called a Receive Window (RW), with the following interpretation. - The RW corresponds to the packets the receiver is allowed to accept. Any packet falling outside the window is discarded. - When a packet with a sequence number equal to the lower-edge of the RW is received, the following actions are taken: o The data part of the packet is passed on to the network layer above. o An ACK is sent to the sender. o The RW is advanced (or, rotated) by 1. Note: When the receiver does not receive an expected packet, an error is said to have occurred, and this situation is handled separately as discussed below. Dealing with errors in the sliding window protocol 12

13 From the sender s viewpoint, an error is said to have occurred if it gets a timeout, and a timeout will occur if an ACK does not arrive. The sender does not receive an ACK because the receiver did not generate one or it was lost. From the receiver s viewpoint, there is an error if an out-of-sequence packet arrives. For example, let the receive window correspond to the sequence of packets 4, 5, 6, and 7. At this moment, the expected packet is one with a sequence number 4. If a packet with a sequence number 4 does not arrive, but what comes in is a packet with sequence number 5, then we say that an out-ofsequence packet has arrived. (Any packet that falls outside the receive window is simply dropped.) Errors are handled in two general, well-known manners in the sliding window protocol. These two error handling schemes are called: - Go-Back-N - Selective Repeat. Go-Back-N In this case, if the receiver fails to receive an expected packet (i.e. an out-of-sequence packet arrives), the receiver discards all packets which do not correspond to the loweredge (expected sequence number) of the receive window. When an out-of-sequence packet is received, the receiver sends an ACK for the most recently received in-sequence packet. Eventually, the sender will get a timeout and retransmit all unacknowledged packets from within the send window. The Go-Back-N scheme requires a receive window of size one. This is because out-ofsequence packets are not buffered by the receiver in this case. The Go-Back-N scheme can cause waste of bandwidth if error rate is high. But, this is a useful scheme if the receiver is low on memory and the error rate is low. Selective Repeat - In this case, all out-of-sequence packets within the receive window are buffered (Packets beyond the receive window are discarded.) For these buffered packets, neither ACKs are sent back to the sender nor the data parts of the packets are delivered to the network layer above. - When the sender gets a timeout, the corresponding packet just one is retransmitted. - If the packet corresponding to the lower-edge of the receive window is correctly received by the receiver, all consecutive packets from the receive window starting with the lower-edge packet are delivered to the network layer above, and an ACK for each packet delivered to the network layer is transmitted to the sender. Note: Selective Repeat if often combined with having the receiver send a negative ACK (NAK) when it detects an error a checksum error or an out-of-sequence error. A NAK stimulates retransmission before the corresponding timer expires. 13

14 Note: Too many short control packets, such as ACKs, flowing in the network is not a good idea simply because they require additional processing, buffer space, and transmissions. Thus, the information fields in an ACK, such as the sequence number of the data packet being ACKed, are inserted into the data packets moving in the direction of the ACK packets. This concept of combining information from an ACK with a data packet in the reverse direction in the same direction as that of the ACK is called piggybacking. Note: Go-Back-N and Selective Repeat schemes are not DLC-level protocols by themselves. Rather, these are error handling schemes to be used with the sliding window protocol. Thus, we have a sliding window protocol with Go-Back-N and another sliding window protocol with Selective Repeat. Comparison of Go-Back-N and Selective Repeat Comparison Metric Go-Back-N Selective Repeat Receive buffer size One Many Efficiency Low High Waste of sender s High Low energy (important in wireless devices) Note: Some practical DLC protocols, such as the PPP (Point-to-Point Protocol) and HDLC (High-level Data Link Control) protocols will be discussed in the tutorial classes. 14

15 15