Computer networks -- 2008-2009 -- 4

From Wikiversity

Quick links: front; agenda; courses 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13; examination.

Important! Please note that the current work serves mainly as general guidance and discussion topics, and is by no means the reference material for the course. For further information please consult the dedicated section.

Protocols (part 2)[edit]

Summary (part 1)[edit]

  • concepts:
    • communication;
    • sender, receiver;
    • information (content), data (message);
    • channel;
    • protocol;
    • syntax vs semantics;
  • classification:
    • ordered vs unordered;
    • reliable vs unreliable;
    • connection-oriented vs connection-less;
    • byte-oriented (stream-oriented) vs message-oriented (datagram-oriented);



  • principles:
    • protocols are broken into smaller (independent) protocols that build one upon another;
    • each protocol should:
    • execute only one thing; (see also single responsibility principle;)
    • communicate (virtually) with its counterpart (or a compatible protocol) on the other side;
    • send data to the other peer, by passing it (only) to the protocol just beneath it;
    • could be compared with top-down development and procedural abstraction;
  • advantages:
    • enhances modularization and reusability of protocols and their implementations;
    • reduces the perceived complexity for one layer; it breaks the complexity into smaller pieces that can be studied and implemented separately;
    • standardizes the network components and the interfaces between them, thus allowing multiple vendors to create competing products;
    • permits interconnection and inter-operation, in which different equipments or protocols can be used to communicate;
    • it allows vendors to create simpler devices that can speak only up to a particular level, and maybe give software that compensates;
    • and non the least it eases explanation and understanding on the way in which the network works;
  • disadvantages:
    • adds data and processing overhead;
    • raises the overall complexity;
    • it could decrease performance;
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;

Service primitives[edit]

  • principles:
    • the communication between two protocols on two neighboring layers is done through a strict interface;
    • the strict interface operations compose the service primitives;
    • they could be seen as library procedures and are usually available as system calls;
    • they depend on (as they are closely related to) the type of targeted protocol;
  • service primitives vs protocols:
    • protocols describe the message structure, encoding, and exchange pattern; they only describe the rules of communication;
    • service primitives describe the available operations for users of a certain protocol;
    • we could see protocols as a black-box internals, and the service primitives as the interface available for the black-box;
    • they are completely decoupled as we can change one without changing the other (as are seen by the direct users); (of course that if we change the protocol we need to change the service primitive implementation, but the service primitive as an interface remains unchanged;)
  • examples:
    • connection-oriented protocols:
      • connect / accept
      • send, receive
      • close
    • connection-less protocols:
      • send, receive
    • real-world example: Berkeley sockets;
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;


  • overview:
    • the process in which each protocol needs to add its own (housekeeping) data to the message, that it further sends to the lower layer protocols;
    • general packet structure:
      • contains the housekeeping data for the current protocol;
      • usually contains the following information:
        • addressing for sender and receiver;
        • error detection or correction codes;
        • synchronization data;
      body / payload
      • the actual data to be sent;
      • usually this is the unmodified message received from the upper layer protocols;
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;




  • problems:
    • how does an entity address another entity?
      • usually we chose a number, or an array of numbers (like in the case of IP), or we could choose a fixed binary string (like in the case of MAC);
      • but we might also use readable strings like in the case of DNS names or URI's (but only in high level protocols);
    • is the address global or only local?
      • for example MAC address is local to the LAN, but IP address could be global; (as seen from reachability point of view;)
    • if the address is global how can we reach it? how do we determine if the other entity is up?
      • are we directly connected to that particular peer?
      • if not what route should we take?
    • do we use an indirection for an address? if so how do we resolve this indirection?
      • for example DNS -- a logical name -- that is resolved to an IP;
    • if we don't have the address of the other entity how do we find it?
    • how do we assign addresses? how do we make sure they are unique?
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;

Segmentation and reassembly[edit]

  • overview:
    • the process in which a protocol takes the data it needs to handle and breaks it into smaller pieces in order to be able to send them to the lower protocol layers;
    • for example:
      • TCP receives a stream of bytes (could be a couple of MB in one operation), but takes these bytes and splits them into packets small enough to be able to handle them (up to 64 KB);
      • IP takes the packets from TCP, but splits them even further in order to send them on the wire (usually up to 1.5 KB);
    • is the reverse process, in which the packets are taken and concatenated to obtain the entire message which must be delivered to higher layers protocols;
  • problems:
    • how do we determine the "small enough" size?
      • TCP has a maximum of 64 KB by specification;
      • IP uses information from the lower layer to determine it;
      • IP could also use empirical tests to find out; (for example for multi-hop paths);
      • for both TCP and UDP we could use the same method as for IP;
    • how do we identify the pieces coming from the same message?
    • what do we do if some pieces are lost or get duplicated?
    • what is the overhead of segmentation and reassembly?
    • how about packets which are too small to efficiently sending them over the network?
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;


  • overview:
    • it resembles segmentation and reassembly in what concerns out of order packets;
    • mostly applicable to connection-oriented protocols;
  • problems:
    • how do we identify the order?
    • what do we do with packets that are missing, or are to further in front (to new packets)? how about too old packets?
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;

Connection control[edit]

  • overview:
    • applicable to connection-oriented protocols;
    • manages the dialogue between (two) peers that spans over multiple data exchanges;
    • negotiates the dialogue parameters, for example:
      • compression and encryption algorithms;
      • acceptable content;
      • quality of service;
    • responsibilities:
      • connection setup (creation);
      • normal data exchange as part of the connection;
      • connection tear-down (destruction);
      • out-of-band data;
  • typical connection creation (three-way-handshake):
      • one peer waits for incoming connections, by waiting for a certain message (in TCP case SYN); (on the server side;)
      • the other peer connects by sending a sending the properly formatted message (as above); (on the client side;)
      • the server sends back a message saying that it accepts the connection (in TCP case ACK);
      • the client sends another message saying that it has understood the acknowledgment (in TCP case another ACK);
  • problems:
    • how do we identify a given session? and how do we match packets within each session?
    • what happens if the lower layer channel breaks?
    • chicken-and-egg problem with acknowledgment packets; how many are enough?
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;

Flow control[edit]

  • overview:
    • peers might have different network channel capacity, or different processing power;
    • the route to the remote peer could encounter congestion;
    flow control
    the method through which we reduce or increase the amount of data that we send through the network;
  • typical solutions:
    • passive protocols that rely on lower layer protocols;
    • passive protocols that just drop newly received packets if they can not handle them;
    • active protocols that explicitly implement flow control mechanisms;
  • problems:
    • we can control only the rate of sent data, and not of the received data;
    • how can we deduce in advance when it is time to increase or decrease the amount of data;
    • can we identify where the problem is? how about identifying the problem nature?
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;

Error control[edit]

  • types:
    error detection
    determining if an error has occurred;
    error correction
    • determining if an error has occurred;
    • trying to recover the original data from the broken data;
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;
    • Computer Networks, 4th edition -- section 3.2 Error Detection and Correction;


  • overview:
    • if at the current layer we have only one channel of communication, then by multiplexing it we mean giving the impression for upper layer protocols, that we can handle multiple connections;
    • it could also work in the reverse direction, meaning the current layer aggregates multiple lower layer channels into a single one;
  • types:
    upward multiplexing
    when one lower layer channel is used to create multiple higher layer channels (first case in the description above);
    downward multiplexing
    when a higher layer channel is obtained by combining multiple lower layer channels (second case in the description above);
  • problems:
    • how do we identify between virtual channels that are multiplexed from the same real channel?
    • how do we balance the bandwidth requirements of different virtual channels?
  • references:
    • Computer Networks, 4th edition -- section 1.3 Network Software;


  • QOS -- quality of service;
  • compression;
  • encryption;
  • authentication;

Network classification[edit]

By spatial spread and size[edit]

LAN (Local Area Network)
  • small spread;
  • small number of nodes;
  • homogeneous environment;
  • high bandwidth (100 Mb/s, even 1Gb/s);
  • low error rate;
  • cheap equipment;
  • easy to administer;
  • low security implications with low risks (at end-nodes);
MAN (Metropolitan Area Network)
  • large spread (over entire towns);
  • could interconnect multiple LAN's;
  • large number of nodes (thousands);
  • heterogeneous environment;
  • medium bandwidth between peers (10Mb/s or 100 Mb/s, even higher);
  • low error rate (caused mostly by congestion);
  • expensive equipment;
  • tedious administration;
  • some security implications with high risks (at end-nodes);
WAN (Wide Area Network)
  • large spread (over entire states or small countries);
  • interconnects multiple MAN's;
  • large number of nodes (millions, even billions in the case of Internet);
  • heterogeneous environment;
  • small bandwidth between peers (1 Mb/s, maybe 10 Mb/s);
  • error rate mostly depends on the underlying technology; (usually small enough;) (caused mostly by communication medium and congestion;)
  • very expensive equipment;
  • very tedious to administer;
  • critical security implications;
WLAN (Wireless Local Area Network);
PAN (Personal Area Network)
  • limited to a couple of devices in a house or office;
  • more and more frequently encountered;
  • references:
    • Computer Networks, 4th edition -- section 1.2 Network Hardware;

By interconnection layout -- Topologies[edit]

  • a physical connection between exactly two nodes;
  • the available bandwidth can be used to full capacity;
  • no security implications;
  • all computers are connected through a single physical connection;
  • each packet is seen by all computers, but only the targeted one should uses it;
  • the computers are passive -- they are not involved in the transmission process;
  • the bandwidth is shared;
  • the cable length is limited;
  • it usually implies using a terminator to stop signals from reflecting at the end of the segment;
  • low resiliency -- if a link is broken the entire network is broken;
  • high security implications;
  • each computer is connected through a physical connection to a central device -- hub or switch;
  • there is a single failure point -- the hub or switch;
  • the device can be passive (it only serves as junction point (hub)) or active (it repeats and enhances the signal (hub / repeater), or it sends the message to an specified target (switch));
  • the bandwidth is limited by the hub processing capacity and the link bandwidth;
  • the total cable length is high;
  • high resiliency -- if a link is broken only that computer will be disconnected;
  • some security concerns;
  • all computers are connected through a single physical channel that is closed / circular;
  • the data flows into a single direction;
  • each computer acts as a repeater relaying the message to it's neighbors -- as a repeater;
  • low resiliency -- the breaking of a link breaks the entire network;
  • high security implications;
  • other topologies:
    • point-to-point links between multiple nodes;
    • fully connected / partially connected;
  • references:
    • Computer Networks, 4th edition -- section 1.2 Network Hardware;

Network architectures[edit]

  • a design decision that should include:
    • physical network topologies (bus, star, etc.);
    • used protocol stacks (TCP/IP, IPX/SPX, etc.) (protocols and their layering);
    • application architecture (client-server, peer-to-peer, distributed, etc.);
  • examples for the Internet:
    • physical network topologies:
      • bus or star for LAN;
      • hierarchical for WAN;
    • protocol stack: TCP/IP;
    • application architecture: mostly client-server or peer-to-peer;

Token ring protocol[edit]

  • overview:
    • token bus -- the adaptation for bus topology;
  • working principle:
    • when the network is idle a token passes through the network from computer to computer in a circular model;
    • if a computer wants to send data it waits to the token, replaces it with a data frame, and sends it as in the case of the token;
    • each computer passes the frame if it is not addressed to it;
    • if the frame is addressed to a computer, it uses the data, and replaces it with a token, thus the cycle is closed;

The current page is (in parts) a recompilation of the following pages (from previous year):