OSI Network Architecture 7 Layers Model

Open Systems Interconnection (OSI) model is a reference model developed by ISO (International Organization for Standardization) in 1984, as a conceptual framework of standards for communication in the network across different equipment and applications by different vendors. It is now considered the primary architectural model for intercomputing and inter-networking communications. Most of the network communication protocols used today have a structure based on the OSI model. The OSI model defines the communications process into 7 layers, dividing the tasks involved with moving information between networked computers into seven smaller, more manageable task groups. A task or group of tasks is then assigned to each of the seven OSI layers. Each layer is reasonably selfcontained, so that the tasks assigned to each layer can be implemented independently. This enables the solutions offered by one layer to be updated without adversely affecting the other layers. The OSI 7 layers model has clear characteristics at each layer. Basically, layers 7 through 4 deal with end to end communications between data source and destinations, while layers 3 to 1 deal with communications between network devices. On the other hand, the seven layers of the OSI model can be divided into two groups: upper layers (layers 7, 6 & 5) and lower layers (layers 4, 3, 2, 1). The upper layers of the OSI model deal with application issues and generally are implemented only in software. The highest layer, the application layer, is closest to the end user. The lower layers of the OSI model handle data transport issues. The physical layer and the data link layer are implemented in hardware and software. The lowest layer, the physical layer, is closest to the physical network medium (the wires, for example) and is responsible for placing data on the medium. The specific description for each layer is as follows: Layer 7: Application Layer

Defines interface-to-user processes for communication and data transfer in network Provides standardized services such as virtual terminal, file and job transfer and operations Layer 6: Presentation Layer

Masks the differences of data formats between dissimilar systems Specifies architecture-independent data transfer format Encodes and decodes data; encrypts and decrypts data; compresses and decompresses data Layer 5: Session Layer

Manages user sessions and dialogues Controls establishment and termination of logic links between users Reports upper layer errors Layer 4: Transport Layer

Manages end-to-end message delivery in network Provides reliable and sequential packet delivery through error recovery and flow control mechanisms Provides connectionless oriented packet delivery Layer 3: Network Layer

Determines how data are transferred between network devices

Routes packets according to unique network device addresses Provides flow and congestion control to prevent network resource depletion Layer 2: Data Link Layer

Defines procedures for operating the communication links Frames packets Detects and corrects packets transmit errors Layer 1: Physical Layer

Defines physical means of sending data over network devices Interfaces between network medium and devices Defines optical, electrical and mechanical characteristics Information being transferred from a software application in one computer to an application in another proceeds through the OSI layers. For example, if a software application in computer A has information to pass to a software application in computer B, the application program in computer A needs to pass the information to the application layer (Layer 7) of computer A, which then passes the information to the presentation layer (Layer 6), which relays the data to the session layer (Layer 5), and so on all the way down to the physical layer (Layer 1). At the physical layer, the data is placed on the physical network medium and is sent across the medium to computer B. The physical layer of computer B receives the data from the physical medium, and then its physical layer passes the information up to the data link layer (Layer 2), which relays it to the network layer (Layer 3), and so on, until it reaches the application layer (Layer 7) of computer B. Finally, the application layer of computer B passes the information to the recipient application program to complete the communication process. The following diagram illustrated this process.

OSI Network Architecture 7 Layers Model - 1 The seven OSI layers use various forms of control information to communicate with their peer layers in other computer systems. This control information consists of specific requests and instructions that are exchanged between peer OSI layers. Headers and Trailers of data at each layer are the two basic forms to carry the control information. Headers are prepended to data that has been passed down from upper layers. Trailers are appended to data that has been passed down from upper layers. An OSI layer is not required to attach a header or a trailer to data from upper layers. Each layer may add a Header and a Trailer to its Data, which consists of the upper layer's Header, Trailer and Data as it proceeds through the layers. The Headers contain information that specifically addresses layer-to-layer

communication. Headers, trailers and data are relative concepts, depending on the layer that analyzes the information unit. For example, the Transport Header (TH) contains information that only the Transport layer sees. All other layers below the Transport layer pass the Transport Header as part of their Data. At the network layer, an information unit consists of a Layer 3 header (NH) and data. At the data link layer, however, all the information passed down by the network layer (the Layer 3 header and the data) is treated as data. In other words, the data portion of an information unit at a given OSI layer potentially can contain headers, trailers, and data from all the higher layers. This is known as encapsulation.

OSI Network Architecture 7 Layers Model - 2 For example, if computer A has data from a software application to send to computer B, the data is passed to the application layer. The application layer in computer A then communicates any control information required by the application layer in computer B by prepending a header to the data. The resulting message unit, which includes a header, the data and maybe a trailer, is passed to the presentation layer, which prepends its own header containing control information intended for the presentation layer in computer B. The message unit grows in size as each layer prepends its own header and trailer containing control information to be used by its peer layer in computer B. At the physical layer, the entire information unit is transmitted through the network medium. The physical layer in computer B receives the information unit and passes it to the data link layer. The data link layer in computer B then reads the control information contained in the header prepended by the data link layer in computer A. The header and the trailer are then removed, and the remainder of the information unit is passed to the network layer. Each layer performs the same actions: The layer reads the header and trailer from its peer layer, strips it off, and passes the remaining information unit to the next higher layer. After the application layer performs these actions, the data is passed to the recipient software application in computer B, in exactly the form in which it was transmitted by the application in computer A.

OSI Network Architecture 7 Layers Model - 3

One OSI layer communicates with another layer to make use of the services provided by the second layer. The services provided by adjacent layers help a given OSI layer communicate with its peer layer in other computer systems. A given layer in the OSI model generally communicates with three other OSI layers: the layer directly above it, the layer directly below it and its peer layer in other networked computer systems. The data link layer in computer A, for example, communicates with the network layer of computer A, the physical layer of computer A and the data link layer in computer B. The following chart illustrates this example. Related Terms: TCP/IP, IBM SNA, AppleTalk, DECnet, Netware, Protocol, Network Architecture TCP stands for Transmission Control Protocol. It is described in STD-7/RFC-793. TCP is a connection-oriented protocol that is responsible for reliable communication between two end processes. The unit of data transferred is called a stream, which is simply a sequence of bytes. Being connection-oriented means that before actually transmitting data, you must open the connection between the two end points. The data can be transferred in full duplex (send and receive on a single connection). When the transfer is done, you have to close the connection to free system resources. Both ends know when the session is opened (begin) and is closed (end). The data transfer cannot take place before both ends have agreed upon the connection. The connection can be closed by either side; the other is notified. Provision is made to close gracefully or just abort the connection. Being stream oriented means that the data is an anonymous sequence of bytes. There is nothing to make data boundaries apparent. The receiver has no means of knowing how the data was actually transmitted. The sender can send many small data chunks and the receiver receive only one big chunk, or the sender can send a big chunk, the receiver receiving it in a number of smaller chunks. The only thing that is guaranteed is that all data sent will be received without any error and in the correct order. Should any error occur, it will automatically be corrected (retransmitted as needed) or the error will be notified if it can't be corrected. At the program level, the TCP stream look like a flat file. When you write data to a flat file, and read it back later, you are absolutely unable to know if the data has been written in only one chunk or in several chunks. Unless you write something special to identify record boundaries, there is nothing you can do to learn it afterward. You can, for example, use CR or CR LF to delimit your records just like a flat text file. At the programming level, TWSocket is fairly simple to use. To send data, you just need to call the Send method (or any variation such as SendStr) to give the data to be transmitted. TWSocket will put it in a buffer until it can be actually transmitted. Eventually the data will be sent in the background (the Send method returns immediately without waiting for the data to be transmitted) and the OnDataSent event will be generated once the buffer is emptied. To receive data, a program must wait until it receives the OnDataAvailable event. This event is triggered each time a data packet comes from the lower level. The application must call the Receive method to actually get the data from the low-level buffers. You have to Receive all the data available or your program will go in an endless loop because TWSocket will trigger the OnDataAvailable again if you didn't Receive all the data. As the data is a stream of bytes, your application must be prepared to receive data as sent from the sender, fragmented in several chunks or merged in bigger chunks. For example, if the sender sent "Hello " and then "World!", it is possible to get only one OnDataAvailable event and receive "Hello World!" in one chunk, or to get two events, one for "Hello " and the other for "World!". You can even receive more smaller chunks like "Hel", "lo wo" and "rld!". What happens depends on traffic load, router algorithms, random errors and many other parameters you can't control.

On the subject of client/server applications, most applications need to know command boundaries before being able to process data. As data boundaries are not always preserved, you cannot suppose your server will receive a single complete command in one OnDataAvailable event. You can receive only part of a request or maybe two or more request merged in one chunk. To overcome this difficulty, you must use delimiters. Most TCP/IP protocols, like SMTP, POP3, FTP and others, use CR/LF pair as command delimiter. Each client request is sent as is with a CR/LF pair appended. The server receives the data as it arrives, assembles it in a receive buffer, scans for CR/LF pairs to extract commands from the received stream, and removes them from the receive buffer.

UDP
Short for User Datagram Protocol, a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive datagrams over an IP network. It's used primarily for broadcasting messages over a network. UDP stands for User Datagram Protocol. It is described in STD-6/RFC-768 and provides a connectionless host-tohost communication path. UDP has minimal overhead:; each packet on the network is composed of a small header and user data. It is called a UDP datagram. UDP preserves datagram boundaries between the sender and the receiver. It means that the receiver socket will receive an OnDataAvailable event for each datagram sent and the Receive method will return a complete datagram for each call. If the buffer is too small, the datagram will be truncated. If the buffer is too large, only one datagram is returned, the remaining buffer space is not touched. UDP is connectionless. It means that a datagram can be sent at any moment without prior advertising, negotiation or preparation. Just send the datagram and hope the receiver is able to handle it. UDP is an unreliable protocol. There is absolutely no guarantee that the datagram will be delivered to the destination host. But to be honest, the failure rate is very low on the Internet and nearly null on a LAN unless the bandwidth is full. TOP Not only the datagram can be undelivered, but it can be delivered in an incorrect order. It means you can receive a packet before another one, even if the second has been sent before the first you just received. You can also receive the same packet twice. Your application must be prepared to handle all those situations: missing datagram, duplicate datagram or datagram in the incorrect order. You must program error detection and correction. For example, if you need to transfer some file, you'd better set up a kind of zmodem protocol. The main advantages for UDP are that datagram boundaries are respected, you can broadcast, and it is fast. The main disadvantage is unreliability and therefore complicated to program at the application level.

ADDRESSING
TCP and UDP use the same addressing scheme. An IP address (32 bits number, always written as four 8-bit number expressed as unsigned 3-digit decimal numbers separated by dots such as 193.174.25.26) and a port number (a 16bit number expressed as a unsigned decimal number).

The IP address is used by the low-level protocol (IP) to route the datagram to the correct host on the specified network. Then the port number is used to route the datagram to the correct host process (a program on the host). For a given protocol (TCP or UDP), a single host process can exist at a time to receive data sent to the given port. Usually one port is dedicated to one process. tcp vs. udp for file transfer i think tcp is an overused protocol; i think udp is an underused protocol. this is an argument i've been having quite a bit with people lately, so i've decided i'll lay out my reasoning here so i don't have to type or recite it at people over and over. since i first wrote this (jan 1998 or so), tcp extensions that fix many of my complaints (selective acknowledgment, large windows, tcp for transactions) have seen more widespread implementation. while they are a step in the right direction (well, t/tcp was a terrible security blunder...), tcp will always be a stream protocol, and thus will never be an optimal transport for some applications. advantages of tcp

the operating system does all the work. you just sit back and watch the show. no need to have the same bugs in your code that everyone else did on their first try; it's all been figured out for you. since it's in the os, handling incoming packets has fewer context switches from kernel to user space and back; all the reassembly, acking, flow control, etc is done by the kernel. tcp guarantees three things: that your data gets there, that it gets there in order, and that it gets there without duplication. (the truth, the whole truth, and nothing but the truth...) routers may notice tcp packets and treat them specially. they can buffer and retransmit them, and in limited cases preack them. tcp has good relative throughput on a modem or a lan.

disadvantages of tcp
the operating system may be buggy, and you can't escape it. it may be inefficient, and you have to put up with it. it may be optimized for conditions other than the ones you are facing, and you may not be able to retune it.

tcp makes it very difficult to try harder; you can set a few socket options, but beyond that you have to tolerate the built in flow control. tcp may have lots of features you don't need. it may waste bandwidth, time, or effort on ensuring things that are irrelevant to the task at hand. tcp has no block boundaries; you must create your own. routers on the internet today are out of memory. they can't pay much attention to tcp flying by, and try to help it. design assumptions of tcp break down in this environment. tcp has relatively poor throughput on a lossy, high bandwidth, high latency link, such as a satellite connection or an overfull t1. tcp cannot be used for broadcast or multicast transmission. tcp cannot conclude a transmission without all data in motion being explicitly acked.

disadvantages of udp

there are no guarantees with udp. a packet may not be delivered, or delivered twice, or delivered out of order; you get no indication of this unless the listening program at the other end decides to say something. tcp is really working in the same environment; you get roughly the same services from ip and udp. however, tcp makes up for it fairly well, and in a standardized manner.

udp has no flow control. implementation is the duty of user programs. routers are quite careless with udp. they never retransmit it if it collides, and it seems to be the first thing dropped when a router is short on memory. udp suffers from worse packet loss than tcp.

advantages of udp
it doesn't restrict you to a connection based communication model, so startup latency in distributed applications is much lower, as is operating system overhead. all flow control, acking, transaction logging, etc is up to user programs; a broken os implementation is not going to get in your way. additionally, you only need to implement and use the features you need. the recipient of udp packets gets them unmangled, including block boundaries. broadcast and multicast transmission are available with udp.