Computer Networks

1
Computer Networks

• Chapter 3
• Data Link Layer
• Prof. Jerry Breecher
• CSCI 280
• Spring 2002

2
The Weeks Ahead
Date Lecture Lab/Project Feb 11 Exam
1 Feb 13 MAC Feb 18 The Data Link
Layer Feb 20 The Data Link Layer Feb
21 Project 1 DUE
3
Chapter Overview

• Data Link Layer
• The main goal of this layer is providing
  reliability to the layers above it.
• 3.1 DLL Design Issues
• What are the services provided by DLL?
• 3.2 Error Detection and Correction
• Adding redundancy in order to find and correct
  errors.
• 3.3 DLL Protocols
• xxx
• 3.4 Sliding Window Protocols
• xxx
• 3.5 Protocol Specification and Verification
• xxx.
• 3.6 Examples

4
DLL Design
Overview

• The concerns at the Data Link Layer include
• What services should be provided to upper layers?
• Framing,
• Error Control.
• Flow Control.

• 3.1 DLL Design Issues
• 3.2 Error Detection and Correction
• 3.3 DLL Protocols
• 3.4 Sliding Window Protocols
• 3.5 Protocol Specification and Verification

5
DLL Design
Overview
The goal of the data link layer is to provide
reliable, efficient communication between
adjacent machines connected by a single
communication channel. Specifically 1. Group
the physical layer bit stream into units called
frames. Note that frames are nothing more than
"packets" or "messages". By convention, we'll
use the term "frames" when discussing DLL
packets. 2. Sender checksums the frame and
transmits checksum together with data. The
checksum allows the receiver to determine when a
frame has been damaged in transit. 3.
Receiver re-computes the checksum and compares it
with the received value. If they differ, an
error has occurred and the frame is
discarded. 4. Perhaps return a positive or
negative acknowledgment to the sender. A
positive acknowledgment indicate the frame was
received without errors, while a negative
acknowledgment indicates the opposite. 5. Flow
control. Prevent a fast sender from overwhelming
a slower receiver. For example, a supercomputer
can easily generate data faster than a PC can
consume it. 6. In general, provide service to
the network layer. The network layer wants to be
able to send packets to its neighbors without
worrying about the details of getting it there
in one piece. At least, the above is what the
OSI reference model suggests. As we will see
later, not everyone agrees that the data link
layer should perform all these tasks.
6
DLL Design
Overview
There are several possible kinds of services that
can be provided to network layers. The Figure is
a reminder of the difference between virtual and
actual communications between layers.
7
DLL Design
SERVICES PROVIDED TO THE NETWORK LAYER
Delivery Mechanisms
8
DLL Design
SERVICES PROVIDED TO THE NETWORK LAYER
Unacknowledged Connection-less Service -- Best
Effort The receiver does not return
acknowledgments to the sender, so the sender has
no way of knowing if a frame has been
successfully delivered. When would such a
service be appropriate? 1. When higher layers
can recover from errors with little loss in
performance. That is, when errors are so
infrequent that there is little to be gained by
the data link layer performing the recovery. It
is just as easy to have higher layers deal with
occasional lost packets. 2. For real-time
applications requiring "better never than late"
semantics. Old data may be worse than no data.
For example, should an airplane bother
calculating the proper wing flap angle using old
altitude and wind speed data when newer data is
already available?
9
DLL Design
SERVICES PROVIDED TO THE NETWORK LAYER

• Acknowledged Connection-less Service --
  Acknowledged Delivery
• The receiver returns an acknowledgment frame to
  the sender indicating that a data frame was
  properly received. The sender keeps connection
  state, but may not necessarily retransmit
  unacknowledged frames.
• Likewise, the receiver may hand received frames
  to higher layers in the order in which they
  arrive, regardless of the original sending order.
  
• Typically, each frame is assigned a unique
  sequence number, which the receiver returns in an
  acknowledgment frame to indicate which frame the
  ACK refers to. The sender must retransmit
  unacknowledged (e.g., lost or damaged) frames.

10
DLL Design
SERVICES PROVIDED TO THE NETWORK LAYER

• Acknowledged Connection-Oriented Service --
  Reliable Delivery
• Frames are delivered to the receiver reliably and
  in the same order as generated by the sender.
• Connection state keeps track of sending order
  and which frames require retransmission. For
  example, receiver state includes which frames
  have been received, which ones have not, etc.

11
DLL Design
FRAMING
The DLL translates the physical layer's raw
bit stream into discrete units (messages) called
frames. How can frame be transmitted so the
receiver can detect frame boundaries? That is,
how can the receiver recognize the start and end
of a frame? We will discuss four
ways Character Count Bit Stuffing
Character stuffing Encoding Violations
12
DLL Design
FRAMING

• Character Count
• Make the first field in the frame's header be the
  length of the frame. That way the receiver knows
  how big the current frame is and can determine
  where the next frame ends.
• Disadvantage Receiver loses synchronization
  when bits become garbled. If the bits in the
  count become corrupted during transmission, the
  receiver will think that the frame contains fewer
  (or more) bits than it actually does.
• Although checksum will detect the frames are
  incorrect, the receiver will have difficulty
  re-synchronizing to the start of a new frame.
  This technique is not used anymore, since better
  techniques are available.

13
DLL Design
FRAMING
Bit Stuffing IDEA Use reserved bit patterns
to indicate the start and end of a frame. For
instance, use the 4-bit sequence of 0111 to
delimit consecutive frames. A frame consists of
everything between two delimiters. Problem
What happens if the reserved delimiter happens to
appear in the frame itself? If we don't remove
it from the data, the receiver will think that
the incoming frame is actually two smaller
frames! Solution Use bit stuffing. Within
the frame, replace every occurrence of two
consecutive 1's with 110. E.g., append a zero
bit after each pair of 1's in the data. This
prevents 3 consecutive 1's from ever appearing in
the frame.
14
DLL Design
FRAMING
Bit Stuffing The receiver converts two
consecutive 1's followed by a 0 into two 1's, but
recognizes the 0111 sequence as the end of the
frame. Example The frame "1 0 1 1 1 0 1" would
be transmitted over the physical layer as "0 1 1
1 1 0 1 1 0 1 0 1 0 1 1 1". Note When using
bit stuffing, locating the start/end of a frame
is easy, even when frames are damaged. The
receiver simply scans arriving data for the
reserved patterns. The receiver will
re-synchronize quickly with the sender as to
where frames begin and end, even when bits in the
frame get garbled. The main disadvantage with
bit stuffing is the insertion of additional bits
into the data stream, wasting bandwidth. How
much expansion? The precise amount depends on
the frequency in which the reserved patterns
appear as user data.
15
DLL Design
FRAMING
Character stuffing Same idea as bit-stuffing,
but operates on bytes instead of bits. Use
reserved characters to indicate the start and end
of a frame. For instance, use the two-character
sequence DLE STX (Data-Link Escape, Start of
TeXt) to signal the beginning of a frame, and the
sequence DLE ETX (End of TeXt) to flag the
frame's end. Problem What happens if the
two-character sequence DLE ETX happens to appear
in the frame itself? Solution Use
character stuffing within the frame, replace
every occurrence of DLE with the two-character
sequence DLE DLE. The receiver reverses the
process, replacing every occurrence of DLE DLE
with a single DLE. Example If the frame
contained "A B DLE D E DLE", the characters
transmitted over the channel would be "DLE STX A
B DLE DLE D E DLE DLE DLE ETX". Disadvantage
A octet is the smallest unit that can be operated
on not all architectures are 8-bit oriented.
16
DLL Design
FRAMING
Encoding Violations Send a signal that doesn't
conform to any legal bit representation. In
Manchester encoding, for instance, 1-bits are
represented by a high-low sequence, and 0-bits by
low-high sequences. The start/end of a frame
could be represented by the signal low-low or
high-high. The advantage of encoding violations
is that no extra bandwidth is required as in bit
or character stuffing. The IEEE 802.4 standard
uses this approach. Finally, some systems
use a combination of these techniques. IEEE
802.3, for instance, has both a length field and
special frame start and frame end patterns.
17
DLL Design
ERROR CONTROL

• Must insure that all frames are eventually
  delivered (possibly in order) to a destination.
  Three components are required to do this
•  
• Acknowledgments, Timers, and Sequence Numbers
• Acknowledgments
•  
• Reliable delivery is achieved using the
  "acknowledgments with retransmission" paradigm.
• 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 only a hint to the sender so that it can
  retransmit a frame right away without waiting for
  a timer to expire.
•  

18
DLL Design
ERROR CONTROL

• 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 repeats of old frames.
• Bits used for sequence numbers depend on the
  number of frames that can be outstanding at any
  one time.

19
DLL Design
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 INITIALIZATION   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.  
20
Error Detection Control
Overview
This section is about putting in enough
redundancy along with the data to be able to
detect (and correct) data errors.

• 3.1 DLL Design Issues
• 3.2 Error Detection and Correction
• 3.3 DLL Protocols
• 3.4 Sliding Window Protocols
• 3.5 Protocol Specification and Verification

21
Error Detection Control
ERROR CORRECTING CODES
  In data communication, line noise is a fact of
life (e.g., signal attenuation, natural
phenomenon such as lightning, and the telephone
worker). 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.   We will introduce some
concepts, and then consider both detection and
correction.   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  
22
Error Detection Control
ERROR CORRECTING CODES
 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. This
count is the Hamming Distance.   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 2m 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 the codes are able to 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 2d 1 bits. Intuitively, after
d errors, the garbled messages is still closer to
the original message than any other legal
codeword.
23
Error Detection Control
ERROR CORRECTING CODES
Parity Bits   A single parity bit is appended to
each data block (e.g. each character in ASCII
systems) so that the number of 1 bits always adds
up to an even (odd) number.   1000000(1)
1111101(0)   The Hamming Distance for parity is
2, and it cannot correct even single-bit errors
(but can detect single-bit errors). As another
example, consider a 10-bit code used to represent
4 possible values   "00000 00000", "00000
11111", "11111 00000", and "11111 11111".
  Its Hamming distance is 5, and we can correct
2 single-bit errors   For instance, "10111
00010" becomes "11111 00000" by changing only
two bits.   However, if the sender transmits
"11111 00000" and the receiver sees "00011
00000", the receiver will not correct the error
properly.   Finally, in this example we are
guaranteed to catch all 2-bit errors, but we
might do better if "00111 00111" contains 4
single-bit errors, we will reconstruct the block
correctly.
24
Error Detection Control
ERROR CORRECTION
    What's the fewest number of bits needed to
correct single bit errors? Let us design a code
containing n m r bits that corrects all
single-bit errors (remember m is the number of
message (data) bits and r is number of redundant
(check) bits)   There are 2m legal messages
(e.g., legal bit patterns).   Each of the m
messages has n illegal codewords a distance of 1
from it. That is, if we systematically invert
each bit in the corresponding n-bit codeword, we
get illegal codewords a distance of 1 from the
original. Thus, each message requires n 1
bits dedicated to it (n that are one bit away and
1 that is the message).   The total number of
bit patterns is ( n 1 ) 2m lt 2n. That is,
all (n1) 2m encoded messages should be
unique, and there can't be fewer messages than
the 2n possible code-words.   Since n m r ,
we get   ( m r 1) 2m lt 2mr or   ( m
r 1) lt 2r   This formula gives the absolute
lower limit on the number of bits required to
detect (and correct!) 1-bit errors.  
25
Error Detection Control
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.
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.   Tanenbaum and you have
worked several examples.
26
DLL PROTOCOLS
Overview
How can two DLL layers communicate in order to
assure reliability? We will look at
increasingly complex protocols to see how this is
done.

• 3.1 DLL Design Issues
• 3.2 Error Detection and Correction
• 3.3 DLL Protocols
• 3.4 Sliding Window Protocols
• 3.5 Protocol Specification and Verification

27
DLL Protocols
Overview
    ELEMENTARY DATA LINK PROTOCOLS   The DLL
provides these services to the Network Layer
above it   Data handed to a DLL by a Network
Layer on one module, are handed to the Network
Layer on another module by that DLL.   The remote
Network Layer peer should receive the identical
message generated by the sender (e.g., if the
data link layer adds control information, the
header information must be removed before the
message is passed to the Network Layer).   The
Network Layer may want to be sure that all
messages it sends, will be delivered correctly
(e.g., none lost, no corruption). Note that
arbitrary errors may result in the loss of both
data and control frames.   The Network Layer may
want messages to be delivered to the remote peer
in the exact same order as they are sent.
  Note It is not always clear that we really
want our data link layer protocol to provide this
type of service. What if we run real-time
applications across the link?   Nonetheless, the
ISO reference model suggests that the data link
layer provide such a service, and we now examine
the protocols that do so.
28
DLL Protocols
OUR METHOD
 THE METHOD WE WILL USE   Look at successive
data link protocols of increasing complexity to
provide reliable, in order, message delivery to
the network layer.   Environment   Assume
DLL executes as a process (scheduleable entity)
with routines to communicate with the Network
Layer above and the Physical Layer below.
  Frames are the unit of transmission. Consists
of data plus control bits (header
information).   Look at data structures and
prototypes on the next few pages this is Figure
3.8.   Of special interest is typedef
struct frame void wait_for_event(
event_type event )   wait_for_event() suspends
the process until an event occurs. Possible
events include requests from the network layer,
the physical layer and the timer.
29
DLL Protocols
BUILDING BLOCKS
define MAX PKT 1024 / determines packet size
in bytes / typedef enum false, true boolean
/ boolean type / typedef unsigned int seq_nr
/ sequence or ack numbers / typedef struct
unsigned char dataMAX PKT
packet / packet definition / typedef enum
data, ack, nak frame_kind / frame kind
definition / typedef struct / frames are
transported in this layer / frame_kind kind
/ what kind of a frame is it? / seq_nr
seq / sequence number / seq_nr ack
/ acknowledgement number / packet info
/ the network layer packet / frame
30
DLL Protocols
BUILDING BLOCKS
/ 1. Wait for an event to happen return its
type in event. / void wait_for_event(event_type
event ) / 2. Fetch a packet from the network
layer for transmission on the channel. / void
from_network_layer( packet p) / 3. Deliver
information from an inbound frame to the network
layer. / void to_network_layer( packet p) /
4. Go get an inbound frame from the physical
layer and copy it to r. / void
from_physical_layer( packet p) / 5. Pass the
frame to the physical layer for transmission.
/ void to_physical_layer( packet p) / 6.
Start the clock running and enable the timeout
event. / void start_timer(seq_nr k) / 7. Stop
the clock and disable the timeout event. / void
stop_timer(seq_nr k) / 8. Start an auxiliary
timer and enable the ack_timeout event. / void
start_ack_timer(void) / 9. Stop the auxiliary
timerand disable the ack_timeout event. / void
stop_ack_timer(void) / 10. Allow the network
layer to cause a network_layer_event. / void
enable_network_layer( void ) / 11. Forbid the
network layer from causing a network_layer_event.
/ void disable_network_layer( void )
31
DLL Protocols
AN UNRESTRICTED SIMPLEX PROTOCOL
    Assumptions   Data transmission in one
direction only (simplex).   No errors take place
on the physical channel.   The sender/receiver
can generate/consume an infinite amount of
data.   Always ready for sending/receiving.   See
the code on the next page Figure 3.9.  
32
DLL Protocols
AN UNRESTRICTED SIMPLEX PROTOCOL
/ Protocol 1 (utopia) provides for data
transmission in one direction only, from sender
to receiver. The communication channel is assumed
to be error free, and the receiver is assumed to
be able to process all the input infinitely
fast. Consequently, the sender just sits in a
loop pumping data out onto the line as fast as it
can. / typedef enum frame_arrival
event_type include "protocol.h" void
sender1(void) frame s / buffer for an
outbound frame / packet buffer / buffer
for an outbound packet / while (true)
from_network_layer(buffer) / go get
something to send / s.info buffer / copy
it into s for transmission / to_physical_layer(
s) / send it on its way / void
receiver1(void) frame r event_type event
/ filled in by wait, but not used here
/ while (true) wait_for_event(event) /
only possibility is frame arrival
/ From_physical_layer(r) / go get the
inbound frame / To_network_layer(r.info) /
pass the data to the network layer /
33
DLL Protocols
SIMPLEX STOP-AND-WAIT PROTOCOL
  Assumptions   No longer assume receiver can
process incoming data infinitely fast.   Sender
ships one frame and then waits for acknowledgment
(stop and wait.)   The contents of the
acknowledgment frame are unimportant.   Data
transmission is one directional, but must have
bi-directional line. Could have a half-duplex
(one direction at a time) physical channel.
  See the code on the next page Figure
3.10.   
34
DLL Protocols
SIMPLEX STOP-AND-WAIT PROTOCOL
/ Protocol 2 (stop-and-wait) also provides for a
one-directional flow of data from sender to
receiver. The communication channel is once again
assumed to be error free, as in protocol 1.
However, this time, the receiver has only a
finite buffer capacity and a finite processing
speed, so the protocol must explicitly
prevent the sender from flooding the receiver
with data faster than it can be handled.
/ typedef enum frame_arrival
event_type include "protocol.h" void
sender2(void) frame s / buffer for an
outbound frame / packet buffer / buffer
for an outbound packet / event_type event
/ frame_arrival is the only possibility
/ while (true) from_network_layer(buffer)
/ go get something to send / s.info
buffer / copy it into s for transmission
/ to_physical_layer(s) / send it on its
way / wait_for_event(event(event) / do not
proceed until given the go ahead /
void receiver2(void) frame r,
s event_type event / filled in by wait, but
not used here / while (true) wait_for_event(
event) / only possibility is frame arrival
/ From_physical_layer(r) / go get the
inbound frame / To_network_layer(r.info) /
pass the data to the network layer
/ to_physical_layers) / send a dummy frame
to awaken sender /
CHECK THIS CODE!!
35
DLL Protocols
SIMPLEX PROTOCOL FOR A NOISY CHANNEL

• SIMPLEX PROTOCOL FOR A NOISY CHANNEL
•  
• Assumptions
•  
• The channel is noisy and we can lose frames (they
  never arrive).
•  
• Simple approach, add a time-out to the sender so
  if no ACK after a certain period, it retransmits
  the frame.
•  
• Scenario of a bug that could happen if were not
  careful
•  
• A transmits frame one
• B receives A1
• B generates ACK
• ACK is lost
• A times out, retransmits
• B gets duplicate copy of A1 (and sends it on to
  network layer.)
•  
• Use a sequence number. How many bits? 1-bit is
  sufficient for this simple case because only
  concerned about two successive frames.
•  

36
DLL Protocols
SIMPLEX PROTOCOL FOR A NOISY CHANNEL
/ Protocol 3 (par) allows unidirectional data
flow over an unreliable channel. / define
MAX_SEQ 1 / must be 1 for protocol 3
/ typedef enum frame_arrival, cksum_err,
timeout event_type include "protocol.h void
sender3(void) seq_nr next_frame_to_send /
Seq number of next outgoing frame / frame s
/ buffer for an outbound frame / packet
buffer / buffer for an outbound packet
/ event_type event / frame_arrival is the
only possibility / next_frame_to_send
0 from_network_layer(buffer) / go get
something to send / while (true) s.info
buffer / copy it into s for transmission
/ s.seq next_frame_to_send / insert
sequence number in frame /
to_physical_layer(s) / send it on its way
/ start_timer( s.seq) / if answer takes
too long, time out / wait_for_event(event(e
vent) / frame arrival or cksum err, or
timeout / if ( event frame_arrival)
from_physical_layers(s) / Get the ACK /
if ( s.ack next_frame_to_send )
from_network_layer( buffer ) / get the next
one to send / inc( next_frame_to_send
) / invert next_frame_to_send /

This is Figure 3.11
37
DLL Protocols
SIMPLEX PROTOCOL FOR A NOISY CHANNEL
void receiver3(void) seq_nr frame_expected fr
ame r, s event_type event while (true)
wait_for_event(event) / only possibility
is frame arrival / if ( frame
event_arrival ) / A valid frame has arrived
/ from_physical_layer(r) / go get the
inbound frame / if ( r.seq frame_expected
) / This is what weve been waiting for /
to_network_layer(r.info) / pass the data
to the network layer /
inc(frame_expected) / next time expect the
other seq / s.ack 1
frame_expected to_physical_layer(s) /
send a dummy frame to awaken sender /

38
DLL Protocols
SIMPLEX PROTOCOL FOR A NOISY CHANNEL
   A Problem unresolved by this protocol is
this   How long should the timer be?   What if
too long? (inefficient)   What if too short? A
problem because the ACK does not contain the
sequence number of the frame which is being
ACK'd. So, which frame is being
ACKd?   Scenario   A sends frame A0 time out of
A resend frame A0 B receives A0, ACKS B receives
A0 again, ACKS again (does not accept) A gets A0
ACK, sends frame A1 A1 gets lost A gets second A0
ACK (assumes its ACK of A1), sends A2 B gets A2
(rejects, not correct seq. number)   Will lose
two frames before getting back on track (with A3)
39
Sliding Window Protocols
Overview
These methods provide much more realism! General
method provides buffering with ACKs.

• 3.1 DLL Design Issues
• 3.2 Error Detection and Correction
• 3.3 DLL Protocols
• 3.4 Sliding Window Protocols
• 3.5 Protocol Specification and Verification

40
Sliding Window Protocols
FEATURES

•   
•  
• Assumptions
•  
• Use more realistic Two-way communication.
•  
• We now have two kinds of frames (containing a
  "kind" field)
•  
• Data
• ACK containing (sequence number of last correctly
  received frame).
•  
• Piggybacking - add acknowledgment to data frames
  going in reverse direction.
•  
• Piggybacking issue For better use of bandwidth,
  how long should we wait for outgoing data frame
  before sending the ACK on its own.

41
Sliding Window Protocols
EXAMPLE
Example of a sliding window protocol. Contains a
sequence number whose maximum value, MaxSeq, is
2n - 1.   For stop-and-wait sliding window
protocol, n 1.   Essentially same as Simplex
Protocol, except ACKs are numbered, which solves
early time out problem. Two-way
communication.   Protocol works, all frames
delivered in correct order.   Requires little
buffer space.   Poor line utilization due to
stop-and-wait. (To be solved in next
example.)   ltltlt Figure 3.13 gtgtgt
42
Sliding Window Protocols
EXAMPLE
/ Protocol 4 (sliding window) is bi-directional
and is more robust than protocol 3 / define
MAX-SEQ 1 / must be 1 for protocol 4 /
typedef enum frame-arrival, cksum-err, timeout
event-type include "protocol.h" void
protocol4 (void) seq-nr next-frame-to-send
/ 0 or 1 only / seq-nr frame-expected
/ 0 or 1 only / frame r, s /
scratch variables / packet buffer /
current packet being sent / event-type
event next-frame-to-send 0 / next
frame on the outbound stream / frame-expected
0 / number of frame arriving frame expect
/ from-network-layer(buffer) / fetch a
packet from the network layer / s.info
buffer / prepare to send the initial frame
/ s.seq next-frame-to-send / insert
sequence number into frame / s.ack 1
-frame-expected / piggybacked ack /
to-physical-layer(s) / transmit the frame
/ start-timer(s.seq) / start the timer
running /
43
Sliding Window Protocols
EXAMPLE
while (true) wait-for-event(event)
/ frame-arrival, cksum-err, or timeout /
if (event frame-arrival) / a frame has
arrived undamaged. / from-physical-layer
(r) / go get it / if (r.seq
frame-expected) Handle inbound frame
stream. / to-network-layer(r.info)
/ pass packet to network layer /
inc(frame-expected) / invert sequence number
expected next / if (r.ack
next-frame-to-send) / handle outbound frame
stream. / from-network-layer(buffer)
/ fetch new pkt from network layer /
inc(next-frame-to-send) / invert sender's
sequence numbe s.info
buffer / construct outbound frame /
s.seq next-frame-to-send / insert sequence
number into it / s.ack 1 -frame-expected
/ seq number of last received frame /
to-physical-layer(s) / transmit a frame /
start-timer(s.seq) / start the timer
running /
44
Sliding Window Protocols
OTHER ISSUES
  Problem with stop and wait protocols is that
sender can only have one unACKed frame
outstanding.   Example   1000 bit frames   1
Mbs channel (satellite)   270 ms propagation
delay   Frame takes 1msec ( 1000 bits/(1,000,000
bits/sec) 0.001 sec 1 msec ) to send. With
propagation delay the ACK is not seen at the
sender again until time 541msec. Very poor
channel utilization. Several solutions are
possible   We can use larger frames, but the
maximum size is limited by the bit error rate of
the channel. The larger the frame, the higher the
probability that it will become damaged during
transmission.   Use pipelining allow multiple
frames to be in transmission simultaneously.
45
Sliding Window Protocols
PIPELINING
  Sender does not wait for each frame to be
ACK'ed. Rather it sends many frames with the
assumption that they will arrive. Must still get
back ACKs for each frame.   Provides more
efficient use of transmit bandwidth, but error
handling is more complex.   What if 20 frames
transmitted, and the second has an error. Frames
3-20 will be ignored at receiver side? Sender
will have to retransmit. What are the
possibilities?   Two strategies for receive
Window size  
46
Sliding Window Protocols
SLIDING WINDOW MECHANISMS
Go back n - equivalent to receiver's window size
of one. If receiver sees bad frames or missing
sequence numbers, subsequent frames are
discarded. No ACKs for discarded
frames.   Selective repeat - receiver's
window size larger than one. Store all received
frames after the bad one. ACK only last one
received in sequence.
47
Sliding Window Protocols
SLIDING WINDOW MECHANISMS
Tradeoff between bandwidth and data link layer
buffer space on the receiver side.   In either
case will need buffer space on the sender side.
Cannot release until an ACK is received.   Use a
timer for each unACK'ed frame that has been
sent.   Must be able to enable/disable network
layer because may not be able to handle more send
data if there are many unACKd frames Window
Size Rules   Potential problem of window sizes
(receiver window size of one)   MaxSeq is 7 (0
through 7) is valid. How big can sender window
be?   Send 0-7. Receive 0-7 (one at a time)
and send ACKS All ACKS are lost Message 0 times
out and is retransmitted Receiver accepts frame 0
(why? - because that is next frame) and passes it
to Network Layer.   So sender window size must
be smaller than MaxSeq.   Look at how this is all
put together in ltltlt Figure 3.16 gtgtgt
48
Sliding Window Protocols
SLIDING WINDOW MECHANISMS
/ Protocol5 (pipelining) allows multiple
outstanding frames. The sender may transmit
up to MAX-SEQ frames without waiting for an ack.
In addition, unlike the previous protocols,
the network layer is not assumed to have a new
packet all the time. Instead, the network
layer causes a network-layer-ready event when
there is a packet to send. / define MAX-SEQ 7
/ should be 2n -1 / typedef enum
frame-arrival, cksum-err, timeout,
network-layer-ready event-type include
"protocol.h" / Return true if (a ltb lt c
circularly false otherwise. / static
boolean between(seq-nr a, seq-nr b, seq-nr c)
if (((a lt b) (b lt c)) ((c lt a) (a lt
b)) ((b lt c) (c lt a))) return(true)
else return(false) static void
send-data(seq-nr frame-nr, seq-nr
frame-expected, packet buffer) /
Construct and send a data frame. / frame s
/ scratch variable / s.info
bufferframe-nr / insert packet into frame
/ s.seq frame-nr / insert sequence
number into frame / s.ack (frame-expected
MAX-SEQ) (MAX-SEQ 1 ) / piggyback ack /
to-physical-layer(s) / transmit the frame
/ start-timer(frame-nr) / start the timer
running /
49
Sliding Window Protocols
SLIDING WINDOW MECHANISMS
void protocol5(void) seq-nr
next-frame-to-send / MAX-SEQ gt 1 used for
outbound stream / seq-nr ack-expected /
oldest frame as yet unacknowledged / seq-nr
frame-expected / next frame expected on
inbound stream / frame r / scratch
variable / packet bufferMAX-SEQ 1 /
buffers for the outbound stream / seq-nr
nbuffered / output buffers currently in
use / seq-nr i / used to index into the
buffer array / event-type event
enable-network-layer() / allow
network-layer-ready events / ack-expected
0 / next ack expected inbound /
next-frame-to-send 0 / next frame going
out / frame-expected 0 / number of
frame expected inbound / nbuffered 0
/ initially no packets are buffered /
50
Sliding Window Protocols
SLIDING WINDOW MECHANISMS
while (true) wait-for-event(event)
/ four possibilities see event-type /
switch(event) case
network_layer_ready / the network layer has a
packet to send / / Accept, save,
and transmit a new frame. /
from-network_layer(buffernext-frame-to-send)
/ fetch new packet / nbuffered
nbuffered I / expand the sender's window /
send-data(next_frame-to-send,
frame-expected, buffer) / transmit the frame
/ inc(next_frame-to-send) /
advance sender's upper window edge /
break case frame-arrival / a data
or control frame has arrived /
from_physical_layer(r) / get incoming frame
from physical layer / if (r.seq
frame-expected) / Frames are accepted
only in order. /
to_network-layer(r.info) / pass packet to
network layer / inc(frame-expected)
/ advance lower edge of receiver's window
/ / Ack n implies n- 1, n -2,
etc. Check this. / while
(between(ack-expected, r.ack, next_frame_to_send))
/ Handle piggybacked ack.
/ nbuffered nbuffered -1 /
one frame fewer buffered /
stop-timer(ack-expected) / frame arrived
intact stop timer /
inc(ack-expected) / contract sender's window
/ break
51
Sliding Window Protocols
SLIDING WINDOW MECHANISMS
case cksum-err break / just ignore
bad frames / case timeout /
trouble retransmit all outstanding frames/
next-frame-to-send ack-expected /
start retransmitting here / for (i
I i lt nbuffered i)
send-data(next-frame-to-send, frame-expected,
buffer) / resend 1 frame /
inc(next-frame-to-send) / prepare to send the
next one / break
if (nbuffered lt MAX-SEQ)
enable_network_layer() else
disable_network_layer()
52
Sliding Window Protocols
PERFORMANCE
  A few pages back, we defined channel
utilization as simply bits-transmitted/capacity.
Now well do it again with a bit more
precision.   What is the channel efficiency of a
stop-and-wait protocol?   F frame size D H
data bits header bits   C channel capacity
(bps)   I propagation delay plus processor
service time (seconds)   A ack size (bits)
  Draw picture   Time between frames Time to
get frame on wire Propagation time for
frame Time to get ACK on wire
Propagation time for ACK F/C I A/C
I   Time spent sending data (doing useful stuff)
D/C   Efficiency D/C
D
D ---------------------
------------------------ ---------------------
------ F/C 2I A/C F 2IC A
D H 2IC A   What here helps or
hinders efficiency?
53
Protocol Specification Verification
Overview
The issue is an age-old one. How do you specify
the operation of a protocol and then assure that
it is working correctly.

• 3.1 DLL Design Issues
• 3.2 Error Detection and Correction
• 3.3 DLL Protocols
• 3.4 Sliding Window Protocols
• 3.5 Protocol Specification and Verification

54
Protocol Specification Verification
How Do You Represent the State You Are In?
  PROTOCOL SPECIFICATION AND VERIFICATION   The
goal of this section is to learn methods of
representing specs.   State Diagrams are a useful
way of verifying that a design is correct and
complete.   Look again at ltltlt Figure 3.11
gtgtgt.   The possible states for this configuration
are represented by (XYZ) where X lt01gt
Sequence number of frame being sent Y lt01gt
Sequence number of frame receiver expects Z
lt01A-gt State of the channel ltSeq. 0Seq.
1ACKemptygt   (0,0,0) sender has sent frame 0,
the receiver expects 0, and frame 0 is on the
channel.   See how this is represented in the
Figure - state diagram.   Useful for
determining Guarantee that some transitions are
NOT possible. Guarantee that no deadlock possible
(every state has a transition out of it.)
55
Examples
HDLC
 HDLC - HIGH LEVEL DATA LINK CONTROL   Adopted
as part of X.25.   A connection oriented 64Kbps
network using either virtual or permanent
circuits.   Bit oriented (uses bit stuffing and
bit delimiters)   3-bit sequence numbers   Up to
7 unACK'ed frames can be outstanding at any time
(how big is the receiver's window?)   ACK's the
"frame expected" rather than last frame received
(any behavior difference between the two? No, as
long as the sender and receiver agree on the same
convention).   Look at control information in the
two Figures.
56
Examples
DLL In The Internet

•   
• Point-to-point lines
• Between routers over leased lines
• Dial-up to a host via a modem
•   
• PPP - Point-to-Point Protocol
•  
• a Standard (RFCs 1661-1663)
•  
• Can be used for dial-up and leased router-router
  lines.
•  
• Provides
•  
• Framing method to delineate frames. Also handles
  error detection.
• Link Control Protocol (LCP) for bringing lines
  up, negotiation of options, bringing them down.
  These are distinct PPP packets.
• Network Control Protocol (NCP) for negotiating
  network layer options.
• Similar to HDLC, but is character-oriented.
• PPP doesnt provide reliable data transfer using
  sequence numbers and acknowledgments as the
  default. Reliable data transfer can be requested
  as an option (as part of LCP).
• Allows an internet provider to reuse IP
  addresses. You get to use an address only for
  the duration of your login.

57
Examples
DLL In ATM

• Transmission Convergence (TC) sublayer (refer
  back to ATM reference model).
•  
• Physical layer is T1, T3, SONET, FDDI.
•  
• This sublayer does header check-summing and cell
  reception.
•  
• Header Checksum
•  
• 5-byte header consists of 4 bytes of virtual
  circuit and control 1 byte of checksum.
• Checksum 4 bytes of header information and store
  in 5th byte.
• Use CRC checksum x8 x2 x 1 and add a
  constant 01010101 bit string.
• Low probability of error (likelihood of fiber) so
  keep it cheap to checksum. Upper layers can
  checksum payload if they like.
• 8-bit checksum field is called Header Error
  Control (HEC).
•  
• Idle Cells
•  
• May have to output dummy cells in a synchronous
  medium (must send cells at periodic times). Use
  idle cells. Also have operation and maintenance
  (OAM) cells. Exchange control and other
  information.

58
Examples
DLL In ATM
Cell Reception   Drop idle cells , pass along
OAM cells.   Need to generate framing
information for underlying technology, but no
framing bits! Use a probabilistic approach of
matching up valid headers and checksums in a
40-bit window.   See the Figure which describes
how to get in synch. Have a state-transition
diagram where we are looking for d consecutive
valid headers.   If a bad cell received (flipped
bit) do not immediately give up on
synchronization.