The Concept of OSI - Explained

The first topic you would be covering while preparing for CCNA would be about the OSI model. Lot of people who read about the OSI wonder about the usefulness of a such a hypothetical model. Why have a model in the first place and where is it actually implemented? Is it implemented while writing a software? Is it implemented while building a network using routers and switches? Can it be coded up using C++(I remember one of my friends asking me about that). How can a model be of use practically? Well 'OSI model' in one word is the "backbone" of the internet. Without a model in place there would ensue caos of the worst kind among vendors of different web based applications. Well don't you agree that in the end internet serves the purpose of helping an application user connect to a server or another client and hence transfer/receive data. Whatever you do on the internet is nothing but transfer of data; for example say you want to visit the site yahoo.com, you go about opening you internet explorer or mozilla depending upon your patriotism to microsoft or linux, and you would type in the url name which is http//:www.yahoo.com and voila the page is displayed. Well like what they say in showbiz, what happens behind the scenes? The answer is "an execution of a complete series of data transfer which follow a definite protocol at every stage". The above statement requires a lot of explanation. For one what is a protocol, when in a layman's language is a set of rules. Society would be in utter chaos if anarchy prevails, wouldn't you agree the same goes for Internet? You need a government which sets up rules and regulation which you have to be obey to be a part of the society. In the case of Internet there are several authoritative bodies who have had to do the gruesome job of setting up protocol which would need to be followed by the application in order to transfer data between the requestor and the provider(a client and a server in most cases). Getting back to the problem of understanding how a site ,which resides in some server belonging to a hosting company in United States or any other country for that matter, can be accessed by any computer connected to the internet (provided the computer has a browser installed). In the above mentioned case browser is the application. Lets say you are using internet explorer (no offence to linux users), in that case what is shown on the screen is a front end developed by the hardworking engineers at Microsoft. The front is the interface for users. The required data, which in our case is the url is typed into the appropriate place. Then like I said above "voila the page appears". Now the entire process can be distributed into several phases of the OSI model. The OSI model consists of the following layers ( which I am sure you as a serious CCNA preper are already aware of) 1.) 2.) 3.) 4.) Application layer Presentation layer Session layer Transport layer

5.) Network layer 6.) Data link layer 7.) Physical layer Like I mentioned before "Internet Explorer is an application". The first four layers that is the application, presentation, session layer and transport layer belong to and are present in any web based application. An application developer has to concentrate on all the four layers in order to develop a properly functioning web based application. Let us understand why a 4 layer approach is required to develop a web based application. Here I provide a bried explanation about all the layers mentioned above

Continue to: OSI Application Layer

The OSI Application Layer

:

If you are reading this tutorial then without a doubt you have a browser running on which this page is being displayed. The browser, I think I am repeating myself but I want to make it very clear, is the application and belongs completely to the category called application layer. It is the user interface the product of all the hula bulla which goes on behind the scenes is displayed on this browser for the user to see. Without a user friendly user interface Internet would be for the geek's and nerds of the world and a normal user would make no sense of it at all. Viewing websites can be accomplished through the use of utilities like Netscape and Internet Explorer, you can also have access to email gateway like mail.yahoo.com through you browser but many users prefer using utilities such as Outlook express which makes life a lot easier when you are inundated by mails day in and day out. Outlook express of Microsoft would be an example of a Email gateway, again emails work on smtp protocol hence the front end is only used to display the mails and the graphics, the connection and the rest would need to be taken care of by the layers below the Session layer. Well so there it is the Application layer is nothing but the front end of any web based application. It might sometimes be required the the application layer checks for the presence of all the resources available before the application can kick start. For example , when you fire an outlook express application , it checks to determine if the email server (like MSN or Yahoo) is reachable.

The Presentation Layer

Let us take the example of an Image. We view several images on the web and I am sure you are aware that image follow several compression standards. Without compressing an Image it would take forever to download it to you browser which might account for increase in blood pressure or early greying of the hair. In the case of images the most popular are tiff and jpeg. Now imagine a web site which contains an image, when the web site is displayed on your browser the image has to be downloaded from the server where the site is hosted. If the compression standard followed in JPEG in that case the application has to be smart enough to make sense of the compressed data and display it one the screen. This is where the presentation layer of the application comes into picture. Any application developed should take care to cater to all the standards presently existent if it wants to be popular among the masses. An internet explorer application would have an interface which reads any image data and converts it into a sensible format (a format which makes sense to the front end). The image can be in TIFF format or JPEG format, its upto the application to handle it and the application written to handle it is the property of Presentation layer. Makes sense doesn't it. So OSI has protocol standards which define how standard data should be formatted. Tasks such as encryption,decryption,compression and decompression belong to the presentation layer. Without the existence of proper standards for the above tasks (like JPEG for images,MPEG for videos are standards of data representation) the life of a software programmer would be one holy nightmare.

The Session Layer

If you are an ardent user of the Yahoo Messenger or any messenger for that matter and if you are popular among you friends, I am sure you would have faced the crisis of replying to several message windows popping up on your screen. Imagine the complexity of the software (yahoo messenger for ex), it has to cater to serveral connections at the same time. Each window is a connection, the front end (the blank space where you type your message) is the application layer, the smiley's and italics that you conjure up are displayed on the window at the receiving end through the presentation layer and each session is maintained by the session layer. Every time you open a new chat window the session layer sets up the connection to the yahoo server and any message received for the window is forwarded to the appropriate window or in other words session layer manages the connections and when the window is closed it tears down the connection. If the messenger has a buggy session layer application I shudder to think about the plight of the messenger user, messages meant for one person might end up in the window of another( I hope you got the picture).

Continue to: OSI Transport Layer

The OSI Transport Layer

:

To understand the functionality of this layer you would need to understand the concept of client/server. In a nutshell client is the consumer and server is the provider. When you launch your web-browser and try to access a website, by typing in its url, your machine becomes a client (joining the milieu of million other clients craving for information). The information which the client seeks is provided by the server. If the client seeks to have a webpage then the request has to be catered to by a webserver, if the client seeks download a file then the request maybe catered to by a ftp server, if the client seeks to access a database the request maybe catered to by a database server (ex a sybase server). The two prerequisites for the client to obtain the information it seeks is that it should be aware of the type of information it seeks and exact resource from where it seeks to obtain the information. Let me explain this with an example, lets say you launch your mail client (Microsoft outlook if you belong to common genre) the first thing that's gonna happen is a hunt for your mail server. While configuring the client you would need to specify the mail server's IP address. Once the client is able to reach the server dumps your mail from the server to your pc (would be a quick process if you are the anti-social kind who hardly gets mails). Mail server like any other server runs a software application, the purpose of this application is to authenticate users and allow them access to their mails. To do this job faithfully it would be required that the server is available 24*7 to cater to the needs of the users/clients (some chaps like to check their mail at 4 am) so the server never sleeps. In fact it continuously listens for requests regardless of whether there are any requests or not. This listening part happens at the software level and yeah this functionality resides at the transport layer. In technical terms the server is said to be listening on a port. A port is nothing but a file pointer. It is only logical because all the incoming requests need buffering (say 1000 clients accessing the mail server at the same instance of time). All the requests are buffered in a file and the server continuously checks the file for requests. Unless we are talking about a multithreaded server, the requests would be catered on FIFO (First In First Out) basis. Mail servers are mostly multithreaded in that they can cater to several requests at a time. Well there is a difference between having only one service personnel catering to the customers at the ticket counter and having 100 service personnel, that's the difference between a single threaded server and multithreaded server. Now like I said the server application is designed to be listening continuously on a port and yet again I would like to remind you that a port is nothing but a file pointer. In the case of a mail server the applications running are SMTP and POP3. SMTP is the application which takes care of allowing

the users to access their mail either by directly checking it on the server or by downloading the mails to the individual clients. SMTP listens on port 23 in accordance with the standards. POP3 is the application which takes care of receiving mails, say when you send a mail to your friend your mail would initially get into the POP3 buffer of your mail server and from there it would be sent to the POP3 buffer of you friend's mail server. When your friend accesses his mail-server to read his mails he is first authenticated by the server (Remember the username and password screen) and then the SMTP application interfaces with the POP3 buffer interface and obtains the mails for the your friends and either dumps it his local pc or allows him to read it on the server itself. POP3 listens on port 110 according to standards. The IETF, IEEE, ISO, NIC and ANSI are some of the organization involved in standards creation. Standards are important because it ensures that a set of rules are in places so the different players (manufacturers) play the game with the same rules (it usually avoids chaos). SMTP, POP3, HTTP, FTP, TFTP, NTP and DNS are examples of popular applications which we use on day to day basis everything time we log onto the internet. Now like I said these are all application so I am talking about Layer7, Layer6 and Layer5 of the OSI layer. But all the server applications need to listen for request from the users that is when they make use of the layer4 of the OSI layer. I mentioned that ports are entities defined at the transport layer (layer 4). If the client wants to access a certain application on the server it should access it on the correct port. Lets say a server is running HTTP, FTP and SMTP/POP3 (We are talking high capacity server here), so there are 4 server applications running on the same machine. HTTP listens on port 80, FTP listens on port 21, SMTP listens on port 23 and POP3 listens on port 110. If you want to access a webpage on this server your machine will send a request to this server on port 80 so that the HTTP application comes into picture, if you want to access mails then your machine would send a request to the server of port 23/110 so the SMTP and POP3 application caters to your request. These popular application have been assigned fixed ports to ensure that clients are able to access the required services on these ports. No matter where the webserver is being installed (America, Australia or Antarctica for that matter) it would listen on port 80 for HTTP requests. The web-server can obviously be designed to listen on a different port but then it would be one heck of a job to tell the whole world that "hey if you want to access my webpage you need to send your request on port 343434" Then there are several other servers designed for use within an office or within a community, in which case the port on which these servers listen is decided by the designer and is advertised to the users/clients. For example in my office we have a server called the Beacon server which listens to request on port 14007 and replies by feeding back a GUI. The concept of ports is an important entity of the transport

layer. We have already discussed the application, presentation and session layer, the actual user data comes from the application layer and is wrapped up by the presentation and session layer to complete the user part of the packet. So let's get it clear, packet is the whole or the end product and the packet comprises of the user part, the transport layer information, the network layer information, the link layer information and the physical layer information. The user part comprises of the application layer information (mostly the user data), the presentation layer information (to facilitate comprehension on the other end) and the session layer information (to ensure the right information goes to the right session). I would like to consider the transport layer, network layer, link layer and physical layer as the machine part because it does not contain any user data. One thing transport, network and link layer have in common is that they all have an addressing schema. The addressing part in transport layer is handled by port numbers, the addressing part in the network layer is handled by IP address in most cases and the addressing part at the link layer is handled by the link address (ex mac address, dlci, vpi/vci). The transport layer functionality is three fold Addressing (fulfilled by the concept of ports) Transport (duh obviously, handled by protocols like TCP, UDP, RTP et al) Error correction I have already explained the part of addressing; let me get on to the concept of transport. In general there are two kinds of transport possible reliable and unreliable. Depending on the application the transport required may vary. For example SMNP which is a network management application uses unreliable transport whereas HTTP uses reliable transport. TCP (Transmission control protocol) defines the protocol for reliable transport and UDP (User datagram protocol) defines the protocol for unreliable transport. SNMP uses UDP at the transport layer whereas HTTP uses TCP at the transport layer. There is also a concept of real time transport and RTP (Real-time transport protocol) defines the protocol for real-time transport. Lets us take it one at a time starting with TCP.

Continue to: TCP/IP Explained TCP :- Its stands true to its name (Transmission control protocol) because it not only ensures a reliable transport but also a controlled transport. Let me explain my statement, when I say reliable transport it means the data delivery is ensured and when I say controlled transport it means congestion control in other words, don't

send the data if the resources at the other end are busy. Let us talk about how the functionality of reliable transport is accomplished at this layer. The concept is quite straight forward, for every packet which is sent the sender requires an acknowledgement from the receiver. If the acknowledgement is not received the packet is resent. One can imagine that this would definitely slow down the transport of packets but this ensure reliability which is the main stay of several applications. If reliability of data is not a inherent requirement the application would be better off using UDP at the transport layer which is much faster as it does not involve the cumbersome process of acknowledging the receipt of every packet. Another point to remember is that TCP is a connection oriented protocol, for every session that the client establishes towards the server TCP establishes a connection by exchanging initiation or handshake packets and once the connection is established data is sent two-way or full duplex over this connection. TCP follows a three way handshaking mechanism to establish a connection in other words three packets (syc, syc+ack and ack) are involved in making a connection. The sequence of events is as below 1) The client sends the SYC segment which contains information about the initial sequence number (ISN) which would be any random number which the clients seeks to use as the initial sequence number for the packets which would be transferred later. There is no data in the sync segment, its just a control packet. 2) The server sends a SYC+ACK segment, it is just one control packet with SYC and ACK flags set, the purpose of the ACK flag is to acknowledge the reciept of the SYC segment sent by the client. The server also uses this segment to initialize the ISN that would be used by the server while sending packets to the client. I wouldn't want to complicate things here but I would want to mention that the when the server sends this SYC+ACK packet it consumes the first sequence number or ISN so when the data transfer starts it would start with ISN+1. It is the same with the client also. 3) The client sends the response to the SYC+ACK packet sent by the server by sending the ACK segment to finish the 3-way handshake. Just to have the statistics clear remember that SYC segment sent by the client consumes one sequence number, SYC+ACK sent by the server consumes a sequence number but ACK segment sent

finally by client doesn't consume any sequence number. The thumb-rule is that ACK packets don't consume sequence number even during the data transfer phase. Once the client and server are done with the above three-way handshake they are ready for data transfer. The data transfer mechanism is straightforward. Here you would need to understand the concept of segmentation. The data which is coming from the application layer would come in huge chunks of bytes; the transport layer segments this stream of bytes into segments and assigns a sequence number (in incrementing fashion) to each of these segments. Once it's done with assigning a sequence number to the segment it passes it on to the networking layer which puts the network header and passes it on to the data link layer (which puts the link layer header). This datagram is then passed over the physical layer to other end point. The transport layer expects a positive ACK for every segment that it sends. The segment is retransmitted if an ACK for that segment is not received before timeout. Every time a segment is transmitted a transmit timer is started for that segment,if an ACK is not received before the timer expires then the segment is retransmitted. This mechanism ensures reliability of data transfer. Let me explain another important feature of TCP while we are dealing with data transfer. Waiting for an ACK per segment causes a lot of delay while transferring large chunk of data, I am sure you agree, so the concept of WINDOWING was introduced. A window is defined as number of segments which can be aggregated for one ACK. In other words if window size is set to 10 it means 10 segments can be sent and if all the 10 are recieved then one ACK is sent back. So one ACK is sent to acknowledge 10 segments. When the ACK packet is recieved the next window is sent. So windowing provides for higher speed of transmission. So who decides the window size in the first place? Well its the reciever who sets it because after all it is the reciever which has to allocate resources (memory/buffer) for the incoming packets so it gets to decide the window size to being with. The window size is sent by the reciever while sending the SYC+ACK packet during the three way handshaking stage. So the windowing per se is one-way through which TCP manages flow control. Now if you remember I had mentioned that TCP has this feature of "congestion control". Now congestion control if you ask me is the numero uno problem in networking. The resources or network components which connect the client to the server (it can be a myriad of routers, switches and links) are inundated by data from all directions from several other clients.

In a poorly managed network there is a high probability of network congestion wherein the network components or the links are unable to handle/process the high amount of data. The only option under these circumstances would be for the network component to drop the data. For example if the bandwidth on a link, connecting the client to the server, is choked up (poor management or unexpected burst traffic could be the reason) in that case any further data would be dropped blindly. The server would be bothered in this case so how is the client to know about the data loss, quite simple it wouldn't receive an ACK for the data sent so it would assume that the data has been lost due to congestion (which is a very logical conclusion). The client would try resending the data and would pray that it succeeds in reaching the server. It would go on resending until it reaches a threshold after which it declares that the other end is not reachable and terminates the connection (We will be discussing connection termination in a short while). Now the question is that if the window size is 8000 bytes would the sender. keeping re-sending 8000 bytes every time it fails to get an ACK for that window? The answer is no it won't. TCP is smart enough to understand that since the transmission failed there must be a network congestion along the path so it performs a function called slow start. If the transmission of a window of size 8000 bytes fails then the system will not reattempt to send 8000 bytes again but would try retransmitting 4000 of the 8000 bytes ( i.e. the window size is now reduced to half the previous value). If the transmission of these new window of 4000 bytes also fails then it transmits 2000 bytes of the initial 8000 bytes and it goes on this way till the TCP session times out. But in case the system receives an ACK for the 2000 bytes sent then it immediately assumes that the network congestion has clear out and sends the next window with the size of 4000 bytes, if ACK is received for this window (6000 bytes of the initial 8000 bytes have now been sent) then it proceeds to change the window size to 8000 bytes again and sends out the window (which would have 2000 bytes from the previous window and 6000 new bytes). I know this is a bit complex to understand but I hope you got the picture. In a nutshell every time a congestion is detected, meaning an ack is not received for the window sent, the window size is reduced to half and resent, this process is called slow start, and if there is a successful transmission during the slow start phase then the system would go into the fast start state when it starts multiplying the window size by 2 until it reaches the original window size. Dividing the window size by 2 when congestion is detected makes logical sense because when there is a

congestion you don't want to make the situation worse by sending more data. Wait till the congestion ceases and start sending again at full capacity. Now arises another logical question; what if the ACK packet is lost during transmission? In other words let's say the sender sends 8000 bytes and the receiver receives these 8000 bytes and sends an ACK for this window to the sender but along the path the ACK is dropped so that the sender doesn't receive it. So the sender would wait till the retransmission timer expires and then it would transmit 4000 bytes (slow start) of the initial 8000 bytes. So the receiver would now receive duplicate packets instead of receiving the new window. This has also been taken care of. The receiver keeps tab of all the sequence number which have already been received during the previous window transmission and it would compare the sequence numbers received with the sequence numbers received previously, if it finds that there has been a duplication then it would send an ACK for the received packets but would drop all the packets (4000 bytes) because it has no need for them as they are duplicates, makes logical sense. Now the receiver gets the ACK and proceeds to send a window of 8000 bytes again (fast start). I hope we are clear about how the congestion control mechanism works for TCP. Now lets move on to the concept of session termination. There comes a point when the client decides to severe its connection with the server because it has finished its transaction and has no need for it, could be the other way round also wherein the server decides to terminate its connection with the client. Whatever be the case the initiator of the termination would send a FIN packet (FIN stands for finish you don't have to be a genius to guess it). Once the receiver gets the FIN packet it would send an FIN+ACK packet to the sender and the sender would send an ACK in reply and once this three way communication takes place both the entities severe their session and free up their resources for future sessions. I don't want to split hairs now but consider a case when FIN packet fails to reach the other end due to congestion i.e. the FIN packet is dropped along the path. In this case since the initiator doesn't receive the FIN+ACK packet from the other end it would keep resending the FIN packet till it receives a FIN+ACK, in the worst case it would have to severe the session once the TCP session times out in which case the entities would severe their sessions and free up the resources for future sessions. So we have come the full circle, the details covered were as mentioned below

 connection initiation through 3 way handshake data transfer congestion control connection termination Next we will discuss about UDP

IP addressing explained
I have explained layer 4 in the previous section which is the transport layer. The packet which get created till the layer 4 will now be ready for routing. The encapsulation of layer 3 would ensure that the PDU gets routed across the internet and reaches the IP destination it is meant for. I will discuss the most popular routing encapsulation in the present date which is IPv4 in this section. I have written a separate article on IPv6 which will be on this site soon. Let us get started with IPv4. The layer 3 or the network layer is the interfacing layer between the data link layer which is the layer 2 and the transport layer which is the layer 4. Layer 3 is of the highest significance as this is the layer which actually takes care of the routing. Layer 7 to layer 4 would come into picture only when the packet reaches the network's destination. The IP layer, data link layer and physical layer would come into picture at every routing hop. The IP layer or layer 3 is nothing but a header which gets added to the PDU formed till layer 4. Let us discuss the IP header. Let me discuss the various fields in the IP header. Each field would be discussed indepth, below is just an overview of each field after that would follow an exhaustive explanation. 1) IP version :- The ip version could take several values from 0-15 out of which 4 represent IPv4. I will not be discussing any of the other values in this section. Its a four bit field with the value 0010 for IPv4 packets. 2) Header length :- This is the length of the IP header 3) ToS :- This field specifies the type of service which would be given to the IP packet 4) Total length :- This specifies the total length of the packet including the header

5) Identifier :- This is to identify the fragments when the IP packet is being reassembled at the destination 6) Flags and Fragment offset :- Used in conjunction with the identifier to reassemble the fragmented IP packets 7) Time to live :- Specifies the maximum number of network hops the IP packet would be allowed to be routed 8) Protocol :- Specifies the protocol which is being used the higher layer 9) Header checksum :- As the name specifies it provides the checksum of the header to ensure that the IP packet is not tampered or corrupted during the transit throught the network 10) Source Address :- Specifies the IP address of the source from the packet is originating 11) Destination Address :- Specifies the IP address of the destination for which the packet is intended 12) Options :-This field is optional and is used primarily for the purpose of testing 13) Padding :- The header needs to end on a 32 bit boundary and this is ensured by adding zeros until the lowest multiple of 32 is reached