Protocols and layering Network protocols and software Layered

Protocols and layering • • Network protocols and software Layered protocol suites The OSI 7 layer model Common network design issues and solutions

The need for protocols • Basic communication hardware can transfer bits from one place to another • Communication software provides a convenient high level interface for application programmers – do not have to deal directly with hardware – can run over different hardware • A set of rules for exchanging messages is a network protocol

Protocol suites • Rather than having a single giant protocol, protocols tend to be structured as suites of specific protocols – design and testing is easier – extension and updating is easier – selection and combination becomes possible

Layering • The most common approach to designing protocol suites • Each layer deals with a different level of abstraction and communicates with the layers above and below through a standard interface • There might be several alternatives for each layer

Example - the OSI 7 layer model • • ISO model for standardising all networks Now 20 years old and woefully out of date Probably too complex However, still provides useful terminology and a good general example of layering

The 7 OSI layers

Conceptual path of data

Commercially available stacks

Multiple nested headers • Each layer places information in a header before passing a packet to a lower layer and removes it before passing it to an upper layer

Layering principle • Layer N software on the destination computer must receive exactly the message sent by layer N software on the sending computer

Common networking issues • • • Sequencing for out-of-order delivery Sequencing to eliminate duplicate packets Re-transmitting lost packets Avoiding replay caused by excessive delay Flow control to prevent data overrun Mechanisms to avoid network congestion

Sequencing for out-of-order delivery • Connectionless network with dynamic routing may deliver packets out of order • Transport protocols solve this with sequencing • Each packet is given a sequence number • The receiver notes the number of the last packet that arrived in sequence and stores additional out of order packets • The packets are delivered in sequence to the next layer up

Sequencing to eliminate duplicates • Malfunctioning hardware can produce multiple copies of a packet • Sequence numbers allow duplicates to be detected and discarded

Re-transmitting lost packets • Packet loss is a fundamental problem due to transmission errors • One approach to reliable transmission involves positive acknowledgements – sender transmits and starts a timer – receiver receives and acknowledges – on time-out the sender transmits again – the receiver must watch out for duplicates – limit number of attempts before giving up

Avoiding replay caused by delay • A duplicate packet might turn up in a later session (e. g. , if it was queued in a switch for a long time) • May be confused with a packet from the later session that uses the same sequence number • Solution is to include a session identifier in the packet

Flow control to prevent overrun • Data overrun occurs when the sender sends faster than the receiver can receive • Simple solution is to acknowledge each packet before sending the next (“stop and go”) • However, this can be wasteful of bandwidth – capacity = 2 Mbps, packet size = 1000 octets, delay = 50 ms – sender has to wait 100 ms before sending next packet – data rate is 1000 octets every 100 ms = 80000 bps = 4% of available capacity

Sliding window protocols • Sender and receiver agree a window size (number of packets) • Initially a whole window is sent • After that, each packet is acknowledged and then another can be sent

Tw = T g x W

Congestion • Congestion arises due to too much traffic and/or bottlenecks in the network • Limited storage in switches means that packets get dropped

Dealing with congestion • Detecting congestion – switches can inform senders – packet loss can be used as a measure of congestion • Solution is rate control

The art of protocol design • The devil is in the detail – small changes in design can have drastic effects – mechanisms can interact in complex and unexpected ways