Data Link Layer

Data Link LayerData Link Layer

• Concerned with the tranmission of “frames” between two directly connected IMP’s. We follow [Tannenbaum]. Note that (prove for ec) -> +5

• IMP=interface message processor (nod or station)

Host IMP

IMP

IMP

Host

HostIMP IMP

IMP

HOST HOST

HOST

• DLL doesn’t worry about which other IMP [network layer]

• DLL doesn’t worry about how to xmit bits [physical layer]

• frame = block of data

• frame -> sync bits, header, info field, error checking.

• header -> kind, seq, ack.

• seq = sequence number.

• kind = classification

• ack = acknowledge (used in two way communications)

• DLL is layer 2

Sending IMP

net layer

data link layer

physical layer

Sending IMP

net layer

data link layer

physical layerphysical

connection

virtual

connection

• The DLL gets packets from the net layer (getp). It sends frames to the other DLL (sendf). The other DLL gets the frames (recf) and returns them to the higher net layer (givep). The receiver has a procedure called wait.

sender 1

getp(packet)

frame.info <- packet

sendf(frame)

wait

recf

packet

givep

frame

frame

receiver 1

• An unrestricted simplex protocol (protocol 1)->problem: could swamp the reciever, no error recovery A simplex stop-and-wait protocol (protocol 2)

getp(packet)

frame.info <-packet

sendf(frame)

sender 2

event=ack

set timer

wait (event)

yes

notimout

event=frame arrival?

wait event

recf(frame)

givep(frame_info)

sendf(ack)

yes

no

reciever 2

• With networks you must have distributed algorithms. The problem with simplex stop and wait, the return channel may have an error. Let s=sender, r=receiver

• s, sends a frame to r.

• r sends an ack to s but it is not recieved by s.

• s times out and retransmits

• r obtains 2nd copy of the frame

• This is known as a duplication error!

• To stop duplication errors we add sequence number, e.g. 0,1,2,3...

• What is the smallest frame identifier we can use? We would like to use the min. number of sequence numbers. Could use 0,1,0,1... because of the stop and wait protocal.

• Known as a “positive acknowledgement/retransmission protocal (par)” [Tanenbaum 89], or sometimes called “complete stop and wait”. This allows data to be transmitted in one direction (half duplex) over a noisy communication channel that garbles and loses frames.

• If frame m is lost of damaged, the receiver will not ack and the sender keeps trying.

• If the receiver gets the wrong seq number, it is rejected as a duplicate.

• The sender waits for a positive ack before advancing to the next frame. It requires the timeout to be long enough to prevent premature times outs, to prevent dups.

• The only ambiguity is between frame m and m+1. If the sender times out too early, while an ack is on the way a dup frame will be sent. The ack arrives and the sender is fooled into thinking the ack is for the frame just sent (not the dup). If the next frame is is lost, the sender will not try to retransmit and the protocol fails. PAR can deadlock if the sender times out too early.

• Protocol 3 (par) postive ack/rexmit protocol

next frame to send <- 0 getp(packet) fr.info <- packet fr.seq <- next fr to send sendf(frame) start timer (seq) waiting(event)

event= fr arr

no

yes

getp(packet) increment next fr. to send

event err or time out

sender 3

frame_expected <-0 wait(event)

event= fr arr

getf(frame)

frame_expected= fr.seq?

givep(frame.info) increment frame_expected

yes

yes

no

no

sendf(ack)

reciever 3

good frame is here

• Sliding window Protocols

• For TFTP [Stevens] the frames and acks are numbered. timeouts occur for any frame, frames are transmitted continuously. No deadlocks can occur. Sliding window protocols remain synchronized in the face of garbled or lost frames. They can handle premature timeouts.

• In TFTP a seperate ACK is always sent when a frame arrives. This is a half-duplex xmission. If transmission were full-duplex, we could improve throughput via piggy backing.

• This involves adding a frame ack code to the next outgoing frame. This means hold up the xmission of the ack till the next frame is ready. If we wait beyond the timeout, the rexmission occurs.

send DATA(n)

(time out)retransmit DATA(n)

receive ACK(n)send DATA(n+1)

receive ACK(n) duplicate

receive ACK(n+1)send DATA(n+2)

receive DATA(n)send ACK(n)

receive DATA(n) (duplicate)

send ACK(n) (duplicate)

receive DATA(n+1)send ACK(n+1)

receive DATA(n+2)send ACK(n+2)

• TFTP takes (with comments and command line processing) 2000 lines of C code.

• The max sequence number is

• , where n=length of the ack field in the frame. For TFTP packets, an ACK takes 4 bytes. Two bytes for the op-code, two bytes for the sequence number. Data blocks may be 512 bytes long.

2n 1

• TFTP will run out of sequence numbers after

•

• bytes are sent without ack.

• Stop-and-wait uses n=1 so that sequence number are 0 and 1.

• A one Bit Sliding Window Protocol. This is stop-and-wait since the sender transmits a frame and waits for its ack. Protocal 4 withstands errors and timeouts

512(2n 1)33,553,920

send DATAL(0)

(time out)retransmit DATAL(0)

receive DATAR(0) ACK(0)send DATAR(1) ACK(0)

receive DATAR(0) ACK(0)(drop on floor)

receive DATAL(1) ACK(1)send DATA(0) ACK(1)

receive DATAL(0)send DATAR(0) ACK(0)

receive DATAL(0) (duplicate)send DATAR(0) ACK(0)

(duplicate)

receive DATAL(1) ACK(0)send DATAR(1) ACK(1)

receive DATAL(0)send ACK(0)

• 1-bit sliding window protocol. ack=#of last frm rcvd.

A sends(0,1,A0)

A gets(0,0,B0)A sends(1,0,A1)


A gets(0,0,B2)A sends(1,0,A3)(seq,ack,pack#)

B gets(0,1,A0)B sends(0,0,B0)




• protocol fails if both xmit at same time, half the frames contain dups.

A sends(0,1,A0)



A gets(1,0,B1)A sends(1,1,A1)(seq,ack,pack#)

B sends(0,1,B0)




B gets(1,1,A1)B sends (0,1,B2)

Go Back N ProtocolGo Back N Protocol

• Suppose the transmission time required for a frame to arrive at the receiver plus the transmission time for the ack to come back is non-trivial.

• E.g. a 50 kbps satellite channel could have a 500 ms round trip time. To xmit a 1000 bit frame takes 20 ms, but it is not until 520 ms that the sender gets an ack and so is blocked 500/520 = 96% of the time.

• Let w=#of frames to xmit before blocking.

• at 20 ms per frame and 500 ms/ack we should set w=(500+20)/20=26 frames (at least)

• This is known as pipelining

• let

• b= channel capacity (bps)

• l = frame size (bits)

• R=round-trip propagation time (sec)

• l/b=time to xmit a frame (sec)

• U=channel utilization (efficiency)

• In stop-and-wait, the line is busy for l/b seconds and idle for R seconds.

Ul

lbR

1000

100050000*500*10 3.03841 500520

if lbR then U.5

if lbR then U .5

• U varies in inverse proportion to the bR product.

U1000

1000X,X 0. 2000

0 500 1e+03 1.5e+03 2e+030.3

0.4

0.5

0.6

0.7

0.8

0.9

1

x

The reciever in the data link layer is required to hand packets to the network layer IN SEQUENCE. If you pipe line then there may be problems:

• A frame is damaged...or lost

• Many frames may fall on the floor w/o feedback to the sender

• What should be done with frames following a damaged frame?

• We have seen that TFTP can have 30MB in a pipe w/o repeating a sequence number...should I drop the pipe if I get a bad frame?

• Go back N and Selective repeat are two solutions to these problems.

• With go back n, the receiver lets all the bits coming out of the pipe fall on the floor, sending no acks. This corresponds to a window size of 1.

• With selective repeat, only the bad frame falls on the floor, the rexmit takes a while, but when it does happen, an assembled in-order sequence is passed to the net layer. This corresponds to a window size of larger than 1. If the window is large (e.g. tftp) the buffer can be big (30 MB) esp if the time out time is long.

• This is an example of trading space for bandwidth.

• If MaxSeq=7 then

• 1. The sender sends frames 0-7

• 2. a piggyback ack for frm 7 arrives at the sender

• 3. the sender sends another 8 frms, again with seq#’s0-7

• 4. Now another ack for frame 7 comes in.

• Question: did all 8 frames in the 2nd batch arrive, or get lost? There is no way to tell, so the number of outstanding frames must be Š MaxSeq.

• Multiple timers are needed for multiple frames.

Selective Repeat

• If the line is poor, the pipe line is big (like TFTP) and the timeouts large, you waste bandwidth.

• To save the pipe, we rexmit selective frames. A list of frames is kept by the recvr. New frame are admitted. Dups are discarded. Frames arrive in any order, up to MaxSeq.

• Problem: the sender sends MaxSeq frames, the rcvr acks are all lost...the sender rexmits and the rcvr gets dups.

• Fix: let the window size = (MaxSeq+1)/2.

• Only frames within the window are accepted.

• If we piggyback on the reverse channel and traffic is light ack length will be long. In protocal 5, after MaxSeq frames, the protocol blocks. Protocal 6 sends a NAK to indicate chksum err.

• In either net TCP does the flow control, connections, checkums, ack, timeouts, dup detecting and sequencing.

• IP establishes message boundaries. UDP does this too.

• IP and UDP are connectionless, unreliable datagram services. Therefore you choose TCP/IP or TCP/UDP [Stevens].

• Protocol performance

• Performance of the Stop-and-wait Protocol

• An unrestricted simplex protocol has U=1 since sender runs flat out.

• Suppose stop-and-wait has fixed-length frames and no piggybacking like Protocol 3 (par) postive ack/rexmit protocol.

• NOTATION

A# of bits in an ACKCchannel capacity in BPSD# of data bits per frameEprob. of a bit being in errorFDH (total frame length)

Assume that the channel is perfect ( )

H# of bits in the frame header

I interrupt and service time + prop. delay

L prob . that a frame or its ACK is lost or damaged

P1 prob . that a data frame is lost or damaged

P2 prob. that an ACK frame is lost or damaged

R mean number of rexmissions per data frame

T time out interval

U channel utilization (efficiency )

W window size

• It takes F/C seconds to xmit a frame and F/C+I seconds for the frame to arrive and get serviced. In F/C + A/C +2I seconds the sender has finished processing the ACK.

• Only D data bits were sent in 2I + (F+A)/C seconds.

UD

HDA2CI

• for a perfect channel. Therefore H+A+2CI are the overhead in the protocol (which contribute nothing if the channel is error free).

• Channels have errors, however. The sender timesout in F/C + T seconds, this uses F+CT bits of bandwidth.

• Total channel cap. for R (=avg #bad frames) and 1 good one is RR((FFCTCT))((FFAA22CICI))

where(1)

(2)

(3)

since

The avg number of transmissions per frame is

kk11

11avgavg__##attemptsattempts kk((11 LL))LLkk 11 11 LL

2probprob__ofof__successfulsuccessful__ xmissionxmission(( 1111PP)) ((1P )

EE[[ XX ]] xxii PPXX (( xxii ))ii

LL11 ((11 PP11 ))((11 PP22 ))

probprob__ofof__kk__attemptsattempts ((11 LL))LLkk 11

• (3b)

•proof:•(3a)

k1 LL k1k1kk ((11 LL ))LLkk 11

11

kLkLkk kLkLkk

subst. (3b) into (3a)(3c)

11

LLkLkLkk kLkLkk

kk11

kk11

11

LLLL

((LL 11))22

LL

((LL 11))2211 LL((LL 11))22

11

11 LL

kLkLkk

kk11

LL

(( LL 11 )) 22

Q.E.D.

• The average number of retransmissions per frame is one less, or:

• (4) RRLL

11 LL

using (4) and the fact that: Total channel cap. for R (=avg #bad frames) and 1 good one is

(5)RR((FF CTCT )) ((FF AA 22CICI ))

UU DD((LL// ((11 LL))))((FFCTCT))((FFAA22CICI))

if the variance of I is low then (6) subst (6) into (5) gives:

(6a)UU

DD

((LL// ((11 LL))))((FFAA22CICI))((FFAA22CICI ))

Documents

Data Link Layer