Download Unit 2 data link layer and more Study notes Computer Networks in PDF only on Docsity!
Unit – 2 Data Link
Layer
Data Link Layer:-
The Data Link Layer is the second layer in the OSI model, above the Physical Layer, which ensures that the error free data is transferred between the adjacent nodes in the network. It breaks the datagrams passed down by above layers and convert them into frames ready for transfer. This is called Framing. It provides two main functionalities:
▲ Reliable data transfer service between two peer network layers ▲ Flow Control mechanism which regulates the flow of frames such that data congestion is not there at slow receivers due to fast senders.
Duties of Data Link Layer:-
- Data Link layer is the 2nd layer of the OSI model. It is used for the reliable transfer of data across data link being used. Data Link Layer gets the raw data from physical layer try to make physical link reliable and provides the methods to activate and maintain the link. It gives guarantee to the higher layers that data send by this layer will be free of errors. It attempts to detect and recover the data that it gets from physical layer.
- It uses two protocols as HDLC and LLC for providing its services. HDLC is known as high Level Data link Control. It is used on point to point data links. It can also be used on multi point data links. We can use it in a number
Error control is concerned with insuring that all frames are eventually delivered (possibly in order) to a destination. How? Three items are required. Acknowledgements:
Typically, reliable delivery is achieved using the ``acknowledgments with retransmission'' paradigm, whereby the receiver returns a special acknowledgment (ACK) frame to the sender indicating the correct receipt of a frame. In some systems, the receiver also returns a negative acknowledgment (NACK) for incorrectly-received frames. This is nothing more than a hint to the sender so that it can retransmit a frame right away without waiting for a timer to expire. Timers:
One problem that simple ACK/NACK schemes fail to address is recovering from a frame that is lost, and as a result, fails to solicit an ACK or NACK. What happens if an ACK or NACK becomes lost? Retransmission timers are used to resend frames that don't produce an ACK. When sending a frame, schedule a timer to expire at some time after the ACK should have been returned. If the timer goes off, retransmit the frame. Sequence Numbers:
Retransmissions introduce the possibility of duplicate frames. To suppress duplicates, add sequence numbers to each frame, so that a receiver can distinguish between new frames and old copies.
Flow Control:-
Flow control deals with throttling the speed of the sender to match that of the receiver. Usually, this is a dynamic process, as the receiving speed depends on such changing factors as the load, and availability of buffer space. One solution is to have the receiver extend credits to the sender. For each credit, the sender may send one frame. Thus, the receiver controls the transmission rate by handing out credits.
Link Management:-
In some cases, the data link layer service must be ``opened'' before use:
- The data link layer uses open operations for allocating buffer space, control blocks, agreeing on the maximum message size, etc.
- Synchronize and initialize send and receive sequence numbers with its peer at the other end of the communications channel.
Error Detection and Correction:-
In data communication, line noise is a fact of life (e.g., signal attenuation, natural phenomenon such as lightning, and the telephone repairman). Moreover, noise usually occurs as bursts rather than independent, single bit errors. For example, a burst of lightning will affect a set of bits for a short time after the lightning strike. Detecting and correcting errors requires redundancy -- sending additional information along with the data. There are two types of attacks against errors: Error Detecting Codes: Include enough redundancy bits to detect errors and use ACKs and retransmissions to recover from the errors. Error Correcting Codes: Include enough redundancy to detect and correct errors. To understand errors, consider the following:
- Messages (frames) consist of m data (message) bits and r redundancy bits, yielding an n = ( m + r )-bit codeword.
- Hamming Distance. Given any two codewords, we can determine how many of the bits differ. Simply exclusive or (XOR) the two words, and count the number of 1 bits in the result.
- Significance? If two codewords are d bits apart, d errors are required to convert one to the other.
- A code's Hamming Distance is defined as the minimum Hamming Distance between any two of its legal codewords (from all possible codewords).
- In general, all possible data words are legal. However, by choosing check bits carefully, the resulting codewords will have a large Hamming Distance. The larger the Hamming distance, the better able the code can detect errors. To detect d 1-bit errors requires having a Hamming Distance of at least d +1 bits. Why? To correct d errors requires 2 d +1 bits. Intuitively, after d errors, the garbled messages is still closer to the original message than any other legal codeword.
Parity Bits
- Bit numbers that are powers of two (e.g., 1, 2, 4, 8, etc.) are check bits; the remaining bits are the actual data bits.
- Each check bit acts as a parity bit for a set of bits (both data and check).
- To determine which parity bits in the codeword cover bit k of the codeword, rewrite bit position k as the a sum of powers of two (e.g., 19 = 1+2+16). A bit is checked by only those check bits in the expansion (e.g., check bits 1, 2, and 16).
- When a codeword arrives, examine each check bit k to verify that it has the correct parity. If not, add k to a counter. At the end of the process, a zero counter means no errors have occurred; otherwise, the counter gives the bit position of the incorrect bit. For instance, consider the ascii character
a'' =1100001''. We know that: - check bit 1 covers all odd numbered bits (e.g, 1, 3, 5, )
- check bit 2 covers bits 2, 3, 6, 7, 10, 11,
- check bit 3 covers bits 4, 5, 6, 7, 12, 13, 14, 15,
- check bit 4 covers bits 8, 9, 10, 11, 12, etc. Thus:
- check bit 1 equals: ?+1+1+0+0+1 = 1
- check bit 2 equals: ?+1+0+0+0+1 = 0
- check bit 3 equals: ?+1+0+0 = 1
- check bit 4 equals: ?+0+0+1 = 1 giving:
Note: Hamming Codes correct only single bit errors. To correct burst errors, we can send b blocks, distributing the burst over each of the b blocks. For instance, build a b -row matrix, where each row is one block. When actually sending the data, send it one column at a time. If a burst error occurs, each block (row) will see a fraction of the errors, and may be able to correct its block. Error correction is most useful in three contexts:
- Simplex links (e.g., those that provide only one-way communication).
- Long delay paths, where retransmitting data leads to long delays (e.g., satellites).
- Links with very high error rates, where there is often one or two errors in each frame. Without forward error correction, most frames would be damaged, and retransmitting them would result in the frames becoming garbled again.
Error Detection:-
Error correction is relatively expensive (computationally and in bandwidth). For example, 10 redundancy bits are required to correct 1 single-bit error in a 1000-bit message. Detection? In contrast, detecting a single bit error requires only a single-bit, no matter how large the message. The most popular error detection codes are based on polynomial codes or cyclic redundancy codes (CRCs). Allows us to acknowledge correctly received frames and to discard incorrect ones. CRC Checksums The most popular error detection codes are based on polynomial codes or cyclic redundancy codes. Idea:
- Represent a k -bit frame as coefficients of a polynomial expansion ranging from to , with the high-order bit corresponding to the coefficient of . For example, represent the string ``11011'' as the polynomial:
- Perform modulo 2 arithmetic (e.g. XOR of the bits)
- Sender and receiver agree on a generator polynomial : G ( x ). ( G ( x ) must be smaller than the number of bits in the message.)
- Append a checksum to message; let's call the message M ( x ), and the combination T ( x ). The checksum is computed as follows: •.1. Let r be the degree of G ( x ), append r zeros to M(x). Our new polynomial becomes •.2. Divide by G ( x ) using modulo 2 arithmetic. •.3. Subtract the remainder from giving us T(x).
- When receiver gets T ( x ), it divides T ( x ) by G ( x ); if T ( x ) divides cleanly (e.g., no remainder), no error has occurred. The presence of a remainder indicates an error. What sort of errors will we catch? Assume:
- the receiver gets T ( x ) + E ( x ), where each bit in E ( x ) corresponds to an error bit.
- k 1 bits indicate k single-bit errors.
- Receiver computes [ T ( x ) + E ( x )]/ G ( x ) = E ( x )/ G ( x ). Will detect:
In order to appreciate the step by step development of efficient and complex protocols such as SDLC, HDLC etc., we will begin with a simple but unrealistic protocol. In this protocol:
- Data are transmitted in one direction only
- The transmitting (Tx) and receiving (Rx) hosts are always ready
- Processing time can be ignored
- Infinite buffer space is available
- No errors occur; i.e. no damaged frames and no lost frames (perfect channel)
The protocol consists of two procedures, a
sender and receiver as depicted below:
/* protocol 1 */
Sender() { forever { from_host(buffer); S.info = buffer; sendf(S); } }
Receiver() { forever
wait(event); getf(R); to_host(R.info); } } A simplex stop-and-wait protocol In this protocol we assume that
- Data are transmitted in one direction only
- No errors occur (perfect channel)
- The receiver can only process the received information at a finite rate
These assumptions imply that the transmitter cannot send frames at a rate faster than the
receiver can process them.
The problem here is how to prevent the sender from flooding the receiver.
A general solution to this problem is to have the receiver provide some sort of feedback to the sender. The process could be as follows: The receiver send an acknowledge frame back to the sender telling the sender that the last received frame has been processed and passed to the host; permission to send the next frame is granted. The sender, after having sent a frame, must wait for the acknowledge frame from the
may be either damaged or lost completely. We
assume that transmission errors in the frame are
detected by the hardware checksum.
One suggestion is that the sender would send a frame, the receiver would send an ACK frame only if the frame is received correctly. If the frame is in error the receiver simply ignores it; the transmitter would time out and would retransmit it.
One fatal flaw with the above scheme is that if the ACK frame is lost or damaged, duplicate frames are accepted at the receiver without the receiver knowing it.
Imagine a situation where the receiver has just sent an ACK frame back to the sender saying that it correctly received and already passed a frame to its host. However, the ACK frame gets lost completely, the sender times out and retransmits the frame. There is no way for the receiver to tell whether this frame is a retransmitted frame or a new frame, so the receiver accepts this duplicate happily and transfers it to the host. The protocol thus fails in this aspect.
To overcome this problem it is required that the receiver be able to distinguish a frame that it is seeing for the first time from a retransmission.
One way to achieve this is to have the sender put a sequence number in the header of each frame it sends. The receiver then can check the sequence number of each arriving frame to see if it is a new frame or a duplicate to be discarded.
The receiver needs to distinguish only 2 possibilities: a new frame or a duplicate; a 1-bit sequence number is sufficient. At any instant the receiver expects a particular sequence number. Any wrong sequence numbered frame arriving at the receiver is rejected as a duplicate. A correctly numbered frame arriving at the receiver is accepted, passed to the host, and the expected sequence number is incremented by 1 (modulo 2).
The protocol is depicted below:
/* protocol 3 */
Sender() { NFTS = 0; /* NFTS = Next Frame To Send */ from_host(buffer); forever { S.seq = NFTS; S.info = buffer; sendf(S);
This protocol can handle lost frames by timing out. The timeout interval has to be long enough
to prevent premature timeouts which could
cause a "deadlock" situation.
Sliding Window Protocols
Piggybacking technique
In most practical situations there is a need for
transmitting data in both directions (i.e.
between 2 computers). A full duplex circuit is
required for the operation.
If protocol 2 or 3 is used in these situations the data frames and ACK (control) frames in the reverse direction have to be interleaved. This method is acceptable but not efficient. An efficient method is to absorb the ACK frame into the header of the data frame going in the same direction. This technique is known as piggybacking.
When a data frame arrives at an IMP (receiver or station), instead of immediately sending a separate ACK frame, the IMP restrains itself and waits until the host passes it the next message. The acknowledgement is then attached to the outgoing data frame using the ACK field in the
frame header. In effect, the acknowledgement gets a free ride in the next outgoing data frame.
This technique makes better use of the channel bandwidth. The ACK field costs only a few bits, whereas a separate frame would need a header, the acknowledgement, and a checksum.
An issue arising here is the time period that the IMP waits for a message onto which to piggyback the ACK. Obviously the IMP cannot wait forever and there is no way to tell exactly when the next message is available. For these reasons the waiting period is usually a fixed period. If a new host packet arrives quickly the acknowledgement is piggybacked onto it; otherwise, the IMP just sends a separate ACK frame.
Sliding window
When one host sends traffic to another it is desirable that the traffic should arrive in the
same sequence as that in which it is dispatched.
It is also desirable that a data link should deliver
frames in the order sent.
A flexible concept of sequencing is referred to as the sliding window concept and the next three protocols are all sliding window protocols.
In all sliding window protocols, each outgoing frame contains a sequence number SN ranging
acknowledgement comes in, it gives the position of the receiving left window edge which indicates what frame the receiver expects to receive next. The sender then rotates its window to this position, thus making buffers available for continuous transmission.
A one bit sliding window protocol: protocol 4
The sliding window protocol with a maximum
window size 1 uses stop-and-wait since the
sender transmits a frame and waits for its
acknowledgement before sending the next one.
/* protocol 4 */
Send_and_receive() { NFTS = 0; FE = 0; from_host(buffer); S.info = buffer; S.seq = NFTS; S.ack = 1-FE; sendf(S); start_timer(S.seq); forever { wait(event); if(event == frame_arrival) {
getf(R); if(R.seq == FE) { to_host(R.info); ++FE; } if(R.ack == NFTS) { from_host(buffer); ++NFTS; } } S.info = buffer; S.seq = NFTS; S.ack = 1-FE; sendf(S); start_timer(S.seq); } }
Pipelining
In many situations the long round-trip time can
have important implications for the efficiency of
the bandwidth utilisation.
As an example, consider a satellite channel with a 500ms round-trip propagation delay. At time t~~=0 the sender starts sending the first frame. Not until at least t~>=~ ms has the acknowledgement arrived back
