Class 19: Ethernet and Token Ring

Held Monday, March 6, 2000

Overview

Today we conclude our discussion of the data-link layer with more details of the sliding window algorithm and new details of token ring networks.

Notes

• Not to stifle your creativity, but I get a lot of email, and when I'm looking for email from my students, I look under their names. If possible, please set your name appropriately when you send email to me. Thanks.
• Are there questions on assignment 4 or assignment 5?
• I will be out of town from Wednesday noon until late Sunday evening. Make sure to talk to me about questions on the assignment before then.
• Read Chapter 3 for next week.

Contents

• Sliding Window Algorithms
• Multinode Protocols
  • Ethernet
  • Token Ring
• General Issues

Summary

• Sliding Window, Revisited
• Token Ring Networks

Sliding Window Algorithms

• Let's now consider the sliding window algorithm in more depth.
• We'll talk about the sender and receiver separately, although this is more typically implemented with each side acting in both ways.
• There are three ``parameters'' to the sliding window protocol:
  • The number of values for sequence numbers (MAXSEQ)
  • The size of the sender's window (SWS)
  • The size of the receiver's window (RWS)
• An intersting aspect of the code in the book: if MAXSEQ is not a multiple of SWS or RWS, then the protocol does not behave uniformly.
• The sender and receiver must also keep track of the sequence number of the last acknowledged frame.
• (There is a subtle bug in the following pseudocode, but I think it provides a clearer alternative to the code in the book.)
• Sender initialization:

  FramedMessage senderWindow[SWS]; // The messages to send
  Process processes[SWS];          // For repeated sends
  int[] seqNums[SWS];              // The sequence numbers for each slot
  int slot = 0;         // The slot for the next message
  int seqNo = 0;        // The sequence number for next message
  int filledSlots = 0;  // The number of slots filled
  int needsAck = 0;     // The number of the first slot that
                        // needs an acknowledgement
  

• When the next layer sends a message

  void sendMessage(byte *message) {
    // Wait until there's room in the window.
    blockUntil(filledSlots < SWS)
    ++filledSlots;
    // Frame the message and put in the window.
    frame(sendWindow[slot], message, seqNo);
    seqNums[slot] = seqNo;
    // Send the message
    physicalSendMessage(sendWindow[slot]);
    // Prepare to send copies
    processes[slot] = createResendProcess(slot);
    // Move on to the next message
    seqNo = (seqNo + 1) % MAXSEQ;
    slot = (slot + 1) % SWS;
  } // sendMessage(byte *message)
  

• The resend process:

  void resend(int slot) {
    while (1) {
      sleep(TIMEOUT);
      physicalSendMessage(sendWindow[slot]);
    }
  }
  

• When an acknowledgement comes in

  void ackReceived(int acknum) {
    // Make sure that it's a useful acknowledgement
    if (!validAcknowledgement(acknum)) 
      return;
    // Clear appropriate messages
    while (seqNums[needsAck] != acknum) {
      killProcess(proccesses[needsAck]);
      clearFrame(senderWindow[needsAck]);
      --filledSlots;
      needsAck++;
    }
    // Ugh.  Duplicated code.  Due to bad design
    killProcess(proccesses[needsAck]);
    clearFrame(senderWindow[needsAck]);
    --filledSlots;
    needsAck++;
  } // ackReceived(int)
  

• Client initialization

  FramedMessage receiveWindow[RWS]; // The messages received
  More to come.
  

Multinode Protocols

• The protocols we've studied so far assume that there are exactly two nodes connected by a ``wire''>
• What if we want to handle multiple nodes on a bus or in a loop?

Ethernet

• Bus topology
• Normal receive strategy:
  • Look at bits
  • If they're for me, read 'em.
  • If not, ignore 'em.
• Normal send strategy:
  • Check if the line is free
  • If so, send something
• Problem: Multiple people send at once
  • Need to be able to observe
  • Need to be able to resolve

Token Ring

• Ring topology (duh)
• A token cycles though the ring.
  • You can only send messages when you have the token.
• A ``ringmaster'' keeps the ring operating nicely.
• Amazingly enough, nodes on the ring can become ringmaster when they determine that there is no ringmaster.

General Issues

• Some of the things that I hope that you've seen in this layer (and that we'll see again in other layers)
• Communication with other layers
• Framing
• Error detection and resolution
• Careful specification of protocols
  • Consideration of special cases
• Fairness