The 7 Layer OSI Model
Open Systems
To understand what TCP/IP is all about, it is important to first comprehend how and why it came to be.
Well, it all comes down to open systems, a term which did not really exist in the computer industry up until a few years ago. An open system can roughly be defined as an architecture 'blueprint' that is readily available. The existence of an open system allows hardware and software manufacturers to build their products on a 'standard' foundation, without having to worry too much about the 'hows' and 'whys' of it all.
The net result is that hardware and software solutions are no longer proprietary (roughly meaning that the solution is unique to a vendor), but instead have become 'standard'.
The 7 Layer OSI Model
Applications which send data over a network shouldn't need to know the exact implementation details of the network. An application shouldn't need how to format data into frames and shouldn't need to know how to tell a network card how to convert the frames into electrical signals. All these details are 'hidden' from the application. Instead, these details are buried within a layer of protocols.
From a networking perspective, an open system refers to a network based on a set of well-defined protocols. These protocols can be grouped into distinct 'layers', where each layer performs a particular 'task'. Only by combining all these layers do we achieve a fully functional network. Such a grouping of layers is often called a stack.
Over twenty years ago, in order to bring all network designers onto a common 'page', a reference model was created called the 7 layer OSI model (where OSI stands for open systems interconnect). This model is an 'ideal' standard, suggesting what a network stack should look like. While the model is now very old (in computer terms) and TCP/IP does not fit the model perfectly, many of the principles and nomenclature are still relevent. Thus, to fully understand TCP/IP, one should first get an understanding of the 7 layer OSI model.
In diagrammatic form, it looks like this:
|
|
A useful mnemonic: All Pros Should Try New Daring Positions! |
Each layer is responsible for particular 'tasks':
- Physical:
This layer is concerned with the physical connectivity of the network itself. It is responsible for permitting data at its most basic form (i.e. bits) to travel through the network medium. This layer specifies how data should be encoded into a form which can be carried by the medium, whether that medium be copper wires, optical fibres, air or other. - Data link:
This layer is concerned with point-to-point data transmission between one node and the next. It is concerned with the correct formatting of data into frames and is responsible for handling and correcting transmission errors between adjacent nodes. - Network:
This layer handles routing and relaying. It is the job of the network layer to examine network topology and thereby provide routing and relaying information. This layer is responsible for sending data from source to target, i.e. between end-points. - Transport:
This layer provides end-to-end data integrity. It is the job of the transport layer to open, maintain and terminate connections between end-points. It handles data verification and transparently controls the re-sending of data when required. This layer enforces the desired form of transport control, which essentially means that the network will be reliable or fast. - Session:
This layer coordinates and synchronises communication between different applications. It provides checkpointing as well as timing and flow control. - Presentation:
This layer handles the task of converting application-specific data into a common machine-independent format (in the outward direction), called canonical representation. In the reverse direction (i.e. incoming data), it does the opposite by converting data in canonical representation to an application-specific format. - Application:
This layer is where the application actually interfaces with the user. Application-level protocols include Telnet and FTP.
Moving through the Stack
When your application needs to send data to another machine, the data becomes chopped into discrete chunks. As these data chunks move down the protocol stack, they become enveloped with more data - in the form of headers and trailers. At each layer, more data is added to envelope the data from the previous layer.
When the data reaches the destination, the protocol-control information in these headers and trailers becomes stripped off a layer at a time, allowing the data to move back up the protocol stack until it finally reaches the application that needs it.
Packets, frames, datagrams and segments
At each stage of the journey through the protocol stack, the data 'chunks' can be referred to using a specific term. For example, at the transport layer, the data becomes enveloped into a discrete data unit called a segment. Similarly, when additional packaging information is added at the network layer, the resulting data unit is referred to as a datagram. At the Data link layer, this data becomes enveloped as a frame. The most common frame structure seen today is the Ethernet frame.
However, it is quite common for data chunks at any level to be referred to using the generic term packet. If the whole frames, datagrams, segments thing gets a bit complicated, then feel free to just use the term packet instead.
What's next
Now move on to look at the TCP/IP protocol stack.
| Just Too Good Last updated: June, 2006 (DJL)
|
Drop me a line