Docstoc

Computer Architecture

Document Sample
Computer Architecture Powered By Docstoc
					Computer Networks
       Chapter 3
     Data Link Layer

   Prof. Jerry Breecher
         CSCI 280
       Spring 2002
         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




                       Chap. 4- MAC                   2
               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



                                  Chap. 4- MAC                                 3
                                                        Overview
       DLL Design

3.1 DLL Design Issues                 The concerns at the Data Link Layer include:
3.2 Error Detection and Correction
                                      1.   What services should be provided to
3.3 DLL Protocols                          upper layers?
3.4 Sliding Window Protocols          2.   Framing,
                                      3.   Error Control.
3.5 Protocol Specification and
     Verification
                                      4.   Flow Control.




                                     Chap. 4- MAC                           4
                                                                        Overview
         DLL Design
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.
                                             Chap. 3- DLL                                           5
                                                   Overview
      DLL Design
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.




                                Chap. 3- DLL                           6
                               SERVICES PROVIDED TO THE
DLL Design                         NETWORK LAYER



             Delivery Mechanisms:



                    UN-Acknowledged   Acknowledged


  Connection-Less    “Best Effort”     Better Quality


    Connection                        Reliable Delivery
     Oriented




                     Chap. 3- DLL                         7
                                                SERVICES PROVIDED TO THE
      DLL Design                                    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?


                                    Chap. 3- DLL                                 8
                                             SERVICES PROVIDED TO THE
       DLL Design                                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.




                                  Chap. 3- DLL                              9
                                            SERVICES PROVIDED TO THE
       DLL Design                               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.




                                 Chap. 3- DLL                            10
                                                     FRAMING
       DLL Design


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:


                                Chap. 3- DLL                           11
                                                           FRAMING
       DLL Design

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.




                                    Chap. 3- DLL                               12
                                                         FRAMING
       DLL Design
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.




                                   Chap. 3- DLL                             13
                                                          FRAMING
       DLL Design
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.



                                   Chap. 3- DLL                               14
                                                                    FRAMING
       DLL Design
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.

                                        Chap. 3- DLL                                 15
                                                       FRAMING
      DLL Design
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.




                                 Chap. 3- DLL                             16
                                                            ERROR CONTROL
       DLL Design
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.




                                        Chap. 3- DLL                                     17
                                                        ERROR CONTROL
      DLL Design

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.




                                     Chap. 3- DLL                                 18
                                                                       FLOW CONTROL
        DLL Design
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.




                                               Chap. 3- DLL                                            19
                                                       Overview
  Error Detection &
       Control

3.1 DLL Design Issues                 This section is about putting in enough
3.2 Error Detection and Correction        redundancy along with the data to be
                                          able to detect (and correct) data
3.3 DLL Protocols                         errors.
3.4 Sliding Window Protocols
3.5 Protocol Specification and
     Verification




                                     Chap. 4- MAC                         20
  Error Detection &                                            ERROR CORRECTING CODES

       Control
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



                                                Chap. 3- DLL                                             21
  Error Detection &                                             ERROR CORRECTING CODES

       Control
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.




                                                Chap. 3- DLL                                              22
  Error Detection &                                          ERROR CORRECTING CODES

       Control
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.




                                              Chap. 3- DLL                                           23
  Error Detection &                                                ERROR CORRECTION

       Control
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 < 2n. That is, all (n+1) * 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 < 2m+r or

( m + r + 1) < 2r

This formula gives the absolute lower limit on the number of bits required to detect (and correct!) 1-bit
     errors.

                                              Chap. 3- DLL                                            24
  Error Detection &                                                ERROR DETECTION

       Control
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.




                                             Chap. 3- DLL                                           25
                                                      Overview
 DLL PROTOCOLS

3.1 DLL Design Issues                 How can two DLL layers communicate in
3.2 Error Detection and Correction       order to assure reliability?
                                      We will look at increasingly complex
3.3 DLL Protocols                        protocols to see how this is done.
3.4 Sliding Window Protocols
3.5 Protocol Specification and
     Verification




                                     Chap. 4- MAC                       26
                                                                            Overview
     DLL Protocols

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.

                                               Chap. 3- DLL                                             27
                                                                       OUR METHOD
     DLL Protocols
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.




                                             Chap. 3- DLL                                           28
                                                        BUILDING BLOCKS
    DLL Protocols
#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 data[MAX 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;




                                      Chap. 3- DLL                                 29
                                                         BUILDING BLOCKS
    DLL Protocols
/* 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 );
                                      Chap. 3- DLL                                30
                                                         AN UNRESTRICTED SIMPLEX
     DLL Protocols                                              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.




                                             Chap. 3- DLL                     31
                                                     AN UNRESTRICTED SIMPLEX
    DLL Protocols                                           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 */
    }
}

                                      Chap. 3- DLL                                     32
                                                              SIMPLEX STOP-AND-WAIT
     DLL Protocols                                                  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.




                                             Chap. 3- DLL                                          33
                                                    SIMPLEX STOP-AND-WAIT
    DLL Protocols                                         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!!
}                                     Chap. 3- DLL                                  34
                                                            SIMPLEX PROTOCOL FOR A NOISY
     DLL Protocols                                                    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 we’re not careful:

1.   A transmits frame one
2.   B receives A1
3.   B generates ACK
4.   ACK is lost
5.   A times out, retransmits
6.   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.

Positive Acknowledgment with Retransmission (PAR): Sender waits for positive acknowledgment before
      advancing to the next data item. (Numerous alternatives to this we will see later.)



                                             Chap. 3- DLL                                           35
                                               SIMPLEX PROTOCOL FOR A NOISY
    DLL Protocols                                        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;          This is Figure         3.11
#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(&event);              /*   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 */
            }
        }
    }
}
                                      Chap. 3- DLL                                       36
                                               SIMPLEX PROTOCOL FOR A NOISY
    DLL Protocols                                        CHANNEL
void receiver3(void)
{
    seq_nr          frame_expected;
    frame           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 we’ve 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 */
        }
    }
}




                                      Chap. 3- DLL                                  37
                                                        SIMPLEX PROTOCOL FOR A NOISY
     DLL Protocols                                                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 ACK’d?

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 it’s ACK of A1), sends A2
B gets A2 (rejects, not correct seq. number)

Will lose two frames before getting back on track (with A3)


                                             Chap. 3- DLL                                    38
                                                       Overview
   Sliding Window
      Protocols

3.1 DLL Design Issues                 These methods provide much more realism!
3.2 Error Detection and Correction
                                      General method provides buffering with
3.3 DLL Protocols                        ACKs.
3.4 Sliding Window Protocols
3.5 Protocol Specification and
     Verification




                                     Chap. 4- MAC                        39
     Sliding Window                                                    FEATURES

        Protocols
Assumptions:

Use more realistic Two-way communication.

We now have two kinds of frames (containing a "kind" field):

1.   Data
2.   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.




                                            Chap. 3- DLL                                       40
     Sliding Window                                                           EXAMPLE

        Protocols
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.)

<<< Figure 3.13 >>>




                                               Chap. 3- DLL                               41
   Sliding Window                                              EXAMPLE

      Protocols
/* 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 */




                                      Chap. 3- DLL                                   42
        Sliding Window                                             EXAMPLE

           Protocols
    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 */
    }
}




                                            Chap. 3- DLL                                 43
     Sliding Window                                                    OTHER ISSUES

        Protocols
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.




                                              Chap. 3- DLL                                           44
    Sliding Window                                                      PIPELINING

       Protocols

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:




                                            Chap. 3- DLL                                         45
    Sliding Window                                      SLIDING WINDOW MECHANISMS

       Protocols
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.




                                            Chap. 3- DLL                                    46
    Sliding Window                                       SLIDING WINDOW MECHANISMS

       Protocols
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 unACK’d 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 <<< Figure 3.16 >>>
                                             Chap. 3- DLL                                            47
     Sliding Window                               SLIDING WINDOW MECHANISMS

        Protocols
/* 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 2^n -1 */
typedef enum {frame-arrival, cksum-err, timeout, network-layer-ready} event-type;
#include "protocol.h"
                                                  /* Return true if (a <=b < c circularly;
                                                      false otherwise. */
static boolean between(seq-nr a, seq-nr b, seq-nr c) {
  if (((a <= b) && (b < c)) || ((c < a) && (a <= b)) || ((b < c) && (c < 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 = buffer[frame-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 */
}
                                        Chap. 3- DLL                                  48
   Sliding Window                            SLIDING WINDOW MECHANISMS

      Protocols

void protocol5(void) {
  seq-nr next-frame-to-send;                   /*   MAX-SEQ > 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            buffer[MAX-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 */




                                      Chap. 3- DLL                                 49
   Sliding Window                               SLIDING WINDOW MECHANISMS

      Protocols
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(&buffer[next-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;                      Chap. 3- DLL                                  50
        Sliding Window                               SLIDING WINDOW MECHANISMS

           Protocols
          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 <= 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 < MAX-SEQ)
          enable_network_layer();
        else
          disable_network_layer();
    }
}




                                           Chap. 3- DLL                                  51
      Sliding Window                                                                 PERFORMANCE

         Protocols
A few pages back, we defined channel utilization as simply bits-transmitted/capacity. Now we’ll 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?




                                                          Chap. 3- DLL                              52
       Protocol                                          Overview
    Specification &
     Verification
3.1 DLL Design Issues                 The issue is an age-old one. How do you
3.2 Error Detection and Correction        specify the operation of a protocol and
                                          then assure that it is working correctly.
3.3 DLL Protocols
3.4 Sliding Window Protocols
3.5 Protocol Specification and
     Verification




                                     Chap. 4- MAC                            53
       Protocol                                   How Do You Represent the State You Are In?
    Specification &
     Verification
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 <<< Figure 3.11 >>>.

The possible states for this configuration are represented by (XYZ) where
X = <0|1>: Sequence number of frame being sent
Y = <0|1>: Sequence number of frame receiver expects
Z = <0|1|A|->: State of the channel; <Seq. 0|Seq. 1|ACK|empty>

(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.)



                                             Chap. 3- DLL                                   54
                                                                            HDLC
           Examples
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.




                                                Chap. 3- DLL                                    55
                                                                    DLL In The Internet
            Examples
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 doesn’t 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.



                                             Chap. 3- DLL                                          56
                                                                         DLL In ATM
          Examples
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.




                                             Chap. 3- DLL                                            57
                                                                           DLL In ATM
          Examples
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.




                                              Chap. 3- DLL                                         58

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:2/9/2012
language:
pages:58